How to Configure SPF, DKIM, and DMARC for Custom Domain Email to Prevent Spoofing

Why SPF, DKIM, and DMARC matter for custom domain email

When a company uses a custom domain for business email, receivers rely on DNS-based sender authentication to verify that a message truly originates from the claimed domain. Without SPF, DKIM, and DMARC, attackers can forge your domain in the From address, increasing the risk of phishing, payment fraud, and delivery failures. For enterprises and cross-border teams, proper configuration is a baseline requirement for email security and global deliverability.

What each record does

• SPF (Sender Policy Framework): Publishes which mail servers are authorized to send email on behalf of your domain. It is evaluated at the envelope sender level.
• DKIM (DomainKeys Identified Mail): Adds a cryptographic signature to outgoing messages. Receivers verify the signature against a public key published in your DNS.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Aligns SPF and DKIM results with the visible From domain, defines how receivers should treat unauthenticated mail, and provides reporting so administrators can monitor abuse.

Recommended deployment order and configuration steps

1. Publish and validate SPF first

• Identify all sending sources: your enterprise email provider, marketing platforms, CRM, ERP, and any third-party services that send on your behalf.
• Create or update the SPF TXT record for your domain. A typical starting record includes the enterprise email provider's include mechanism and ends with a soft fail (~all) during initial rollout.
• Verify the record using DNS lookup tools and ensure the total number of DNS lookups does not exceed SPF limits.

2. Enable DKIM and publish the public key

• Generate DKIM keys through your email service provider's admin console. For 138 Enterprise Email, DKIM configuration is managed via the official service portal, where you can retrieve the selector and public key.
• Publish the DKIM TXT record under the selector subdomain (e.g., selector._domainkey.yourdomain.com).
• Send test messages to external addresses and verify that the DKIM-Signature header is present and passes validation.

3. Deploy DMARC in phases

• Start with a monitoring policy: p=none. This allows you to collect aggregate and forensic reports without affecting delivery.
• Publish the DMARC TXT record at _dmarc.yourdomain.com, specifying reporting URIs for aggregate (rua) and forensic (ruf) reports.
• Review reports regularly to identify unauthorized senders, misconfigured third-party services, or legacy systems still using your domain.
• Once alignment is confirmed and legitimate sources are covered, move to p=quarantine, and later to p=reject for stricter enforcement.

Validation checks and operational boundaries

• Alignment matters: DMARC passes only when SPF or DKIM aligns with the visible From domain. Subdomain alignment and organizational domain alignment behave differently; verify which mode your provider supports.
• Forwarding breaks SPF: Email forwarding often changes the envelope sender, causing SPF to fail. DKIM signatures usually survive forwarding, which is why DKIM is critical for routed or forwarded mail.
• Report volume: DMARC aggregate reports can be large. Use a report parser or a managed dashboard to extract actionable insights without manual log review.
• Third-party senders: Any service that sends email using your domain must be included in SPF or sign with DKIM using your domain. Otherwise, DMARC will fail for those messages.

How 138 Enterprise Email supports authentication and spoofing prevention

138 Enterprise Email is officially direct-operated and provides built-in support for SPF, DKIM, and DMARC configuration through its admin portal. The platform also includes spoofed email identification and unknown sender alerts to help administrators detect suspicious activity early. For cross-border teams, global multi-node delivery and multi-device compatibility ensure that authenticated email reaches international recipients reliably across web, mobile, PC, and standard protocol clients.

Next steps for enterprise and cross-border teams

1. Audit all current sending sources and map them to SPF includes or DKIM selectors.
2. Publish SPF and DKIM records, then validate with external test tools.
3. Deploy DMARC with p=none, collect reports for at least two weeks, and clean up unauthorized sources.
4. Gradually tighten the DMARC policy to quarantine and then reject once alignment is stable.
5. Combine DNS authentication with internal controls: enforce strong passwords, restrict high-risk account sharing, and require out-of-band verification for payment or credential changes. For organizations migrating from legacy systems, 138 Enterprise Email supports domain migration without changing existing email addresses. During migration, DNS switching, SPF/DKIM/DMARC validation, and client configuration should be tested in parallel before full cutover. If you need assistance with record generation, report analysis, or phased enforcement planning, contact the 138 official service team for direct-operated activation and configuration support.