Email authentication is no longer optional. Without SPF, DKIM, and DMARC records properly configured, your legitimate messages risk landing in spam folders or being rejected outright by major providers. Worse, attackers can impersonate your domain to phish your customers or partners. This checklist walks you through each protocol in order, with concrete steps you can verify at each stage.
Why This Matters
SPF tells receiving servers which mail servers are allowed to send email for your domain. DKIM adds a cryptographic signature proving messages were not altered in transit. DMARC ties them together and instructs receivers what to do when authentication fails. Together, they form the industry standard for email authentication.
Major inbox providers have tightened enforcement. Domains without proper authentication see lower deliverability rates. More importantly, unauthenticated domains remain vulnerable to spoofing attacks that damage reputation and trust.
Pre-Flight: What You Need
Before starting, gather:
- DNS zone access for your domain with the ability to add TXT records
- List of all mail sources that send as your domain: your web host, transactional email services, marketing platforms, office suite providers
- cPanel or server access if you host email on your own infrastructure and need to generate DKIM keys
- A test email account at Gmail, Outlook, or another major provider for verification
Document every legitimate mail source now. Missing even one can cause authentication failures once DMARC is enforced.
SPF Setup Checklist
SPF is a single TXT record published at the root of your domain. It lists authorized sending sources using IP addresses, hostnames, and include mechanisms.
Step 1: Identify All Sending Sources
List every service that sends email as your domain:
- Your web hosting server or VPS
- Transactional email services (SendGrid, Mailgun, Amazon SES)
- Marketing platforms (Mailchimp, Sendinblue)
- Office email (Google Workspace, Microsoft 365)
- Help desk or CRM tools
- Any scripts or applications that send mail
For each source, determine whether you will reference it by IP address, hostname, or SPF include mechanism. Check the vendor's documentation for their recommended SPF syntax.
Step 2: Build Your SPF Record
An SPF record follows this pattern:
v=spf1 <mechanisms> <qualifier>
Common mechanisms:
ip4:203.0.113.5— authorize a specific IPv4 addressip6:2001:db8::1— authorize an IPv6 addressa— authorize the A record of your domainmx— authorize your MX record serversinclude:_spf.google.com— include another domain's SPF policy
Qualifier at the end:
~all(soft fail) — recommended during testing; flags failures but doesn't reject-all(hard fail) — reject mail from unlisted sources; use once confident your list is complete?all(neutral) — no policy; avoid this
Example for a domain hosted on a VPS with Google Workspace:
v=spf1 ip4:198.51.100.10 include:_spf.google.com ~all
Step 3: Check SPF Record Length
SPF records are limited to 255 characters per string and 10 DNS lookups total. Each include or mx mechanism counts as a lookup. If you exceed the lookup limit, SPF fails entirely.
To stay under the limit:
- Use IP addresses instead of hostnames where possible
- Consolidate services where feasible
- Avoid chaining multiple
includestatements from third parties
Use an SPF validator to count lookups before publishing.
Step 4: Publish the SPF Record
Add a TXT record at the root of your domain:
- Name/Host:
@or leave blank (depending on your DNS provider) - Type: TXT
- Value: your complete SPF record
- TTL: 3600 (1 hour) initially; increase to 86400 once stable
Publish only one SPF record. Multiple SPF records cause all of them to fail.
Step 5: Verify SPF
Wait for DNS propagation, then check:
dig TXT yourdomain.com +short
You should see your SPF record. Use an online SPF checker to validate syntax and lookup count.
Send a test email from each mail source to a Gmail address, then view the original message headers. Look for:
Received-SPF: pass
If you see softfail or fail, verify the sending IP is included in your SPF record.
DKIM Setup Checklist
DKIM adds a digital signature to outgoing messages. Receiving servers verify the signature using a public key published in your DNS.
Step 1: Generate DKIM Keys
If your mail server is cPanel-based, DKIM key generation is built in:
- Log into WHM or cPanel
- Navigate to Email Deliverability or Email Authentication
- Select your domain and click Install the suggested records or Enable DKIM
- cPanel generates a 1024-bit or 2048-bit keypair and shows you the DNS record
For a standalone mail server or Postfix setup, generate keys manually:
opendkim-genkey -s default -d yourdomain.com
This creates two files: default.private (keep secure on your mail server) and default.txt (the public key for DNS).
For third-party services like SendGrid or Mailgun, follow their DKIM setup instructions. They provide the public key and DNS record format.
Step 2: Publish the DKIM Record
DKIM records are published as TXT records at a subdomain called the selector. The format is:
<selector>._domainkey.yourdomain.com
Common selectors: default, mail, s1, or a service-specific name like google or sendgrid.
The record value looks like:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA...
Add a TXT record:
- Name/Host:
default._domainkey(or your selector) - Type: TXT
- Value: the complete DKIM public key string
- TTL: 3600
If the key is too long for a single string, split it into multiple quoted strings without spaces:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..." "...remaining_key_data"
Step 3: Configure Your Mail Server
For cPanel, enabling DKIM in the interface automatically configures the mail server.
For Postfix with OpenDKIM:
- Place the private key in
/etc/opendkim/keys/yourdomain.com/default.private - Edit
/etc/opendkim/KeyTableand add:default._domainkey.yourdomain.com yourdomain.com:default:/etc/opendkim/keys/yourdomain.com/default.private - Edit
/etc/opendkim/SigningTableand add:*@yourdomain.com default._domainkey.yourdomain.com - Restart OpenDKIM:
bash systemctl restart opendkim
For third-party services, DKIM signing is automatic once the DNS record is verified.
Step 4: Verify DKIM
Query the DKIM record:
dig TXT default._domainkey.yourdomain.com +short
Send a test email to a Gmail address, view the original message, and look for:
dkim=pass header.d=yourdomain.com
If you see dkim=fail or no DKIM header, check that the selector matches and the private key is correctly installed on your mail server.
DMARC Setup Checklist
DMARC builds on SPF and DKIM. It tells receiving servers what to do when authentication fails and where to send aggregate and forensic reports.
Step 1: Create a DMARC Monitoring Mailbox
DMARC reports are sent to an email address you specify. Create a dedicated mailbox like [email protected] or use a third-party DMARC monitoring service to parse reports automatically.
Step 2: Build Your DMARC Record
A DMARC record is published as a TXT record at _dmarc.yourdomain.com. The basic syntax:
v=DMARC1; p=none; rua=mailto:[email protected]
Key tags:
v=DMARC1— version identifier (required)p=— policy for the domain:none,quarantine, orrejectrua=— aggregate report destination (daily XML reports)ruf=— forensic report destination (individual failure samples)sp=— policy for subdomains (defaults to the domain policy)pct=— percentage of mail to apply the policy to (default 100)adkim=— DKIM alignment mode:r(relaxed) ors(strict)aspf=— SPF alignment mode:rors
Step 3: Start with Policy None
Always begin with p=none to monitor authentication results without affecting delivery:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Publish this and monitor reports for at least two weeks. Reports reveal which sources are passing or failing authentication.
Step 4: Publish the DMARC Record
Add a TXT record:
- Name/Host:
_dmarc - Type: TXT
- Value: your DMARC policy
- TTL: 3600
Step 5: Monitor and Analyze Reports
Aggregate reports arrive daily as gzipped XML files. They show:
- Sending sources (IP addresses, hostnames)
- SPF and DKIM authentication results
- Message volume and disposition
Look for:
- Legitimate sources failing authentication: add them to SPF or configure DKIM
- Unknown sources: investigate whether they are authorized or spoofing attempts
Forensic reports (if enabled) provide message samples for failed authentication, but many receivers no longer send them due to privacy concerns.
Step 6: Harden Your Policy
Once confident that all legitimate mail passes authentication, escalate your policy:
- Change
p=nonetop=quarantine— sends failing mail to spam - Monitor for one to two weeks
- Change to
p=reject— instructs receivers to reject failing mail outright
Final hardened policy example:
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100
Step 7: Verify DMARC
Query the DMARC record:
dig TXT _dmarc.yourdomain.com +short
Send a test email and check the headers:
dmarc=pass action=none header.from=yourdomain.com
Use an online DMARC validator to confirm syntax.
Common Pitfalls
Multiple SPF records: Only one SPF record is allowed. If you have multiple, all fail.
Exceeding SPF lookup limit: Each include and mx counts toward the 10-lookup limit. Going over breaks SPF entirely.
Forgetting a mail source: An unlisted source will fail SPF and trigger DMARC failures once your policy is enforced.
DKIM key length: 1024-bit keys are still common but 2048-bit keys offer better security. Check your provider's recommendations.
Alignment issues: DMARC requires either SPF or DKIM to pass and align (the From domain matches the authenticated domain). Relaxed alignment allows subdomain matches; strict requires exact matches.
Jumping to p=reject too quickly: Always start with p=none and analyze reports. Prematurely enforcing rejection can block legitimate mail.
Subdomain Considerations
By default, your DMARC policy applies to all subdomains unless they have their own _dmarc record. If you send mail from subdomains like news.yourdomain.com, either:
- Publish separate SPF, DKIM, and DMARC records for each subdomain, or
- Use the
sp=tag in your main DMARC record to set a subdomain policy:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]
For subdomains that never send mail, publish a restrictive DMARC policy to prevent spoofing:
v=DMARC1; p=reject; rua=mailto:[email protected]
Ongoing Maintenance
Email authentication is not set-and-forget. Review DMARC reports monthly and update records when:
- Adding new mail services or infrastructure
- Migrating mail servers or changing hosting providers
- Retiring old mail sources
Rotate DKIM keys annually as a security best practice, especially if keys are shorter than 2048 bits.
Conclusion
SPF, DKIM, and DMARC form the foundation of modern email authentication. Following this checklist ensures your domain's email is trusted by major inbox providers and protected from impersonation. Start with SPF to authorize sending sources, add DKIM for cryptographic proof, and tie them together with DMARC for policy enforcement and visibility. Begin with monitoring mode, analyze reports, and harden your policy incrementally. Proper authentication improves deliverability and defends your domain reputation against spoofing attacks.