Why Email Authentication Matters

Every day, billions of emails cross the internet, and a significant portion of them are fraudulent. Spoofed emails, phishing attacks, and impersonation attempts cost businesses billions annually. Email authentication protocols — SPF, DKIM, and DMARC — are the foundation of a secure email ecosystem. Without them, your domain is vulnerable to being forged, your legitimate messages risk being flagged as spam, and your brand reputation can suffer irreparable damage.

Configuring these DNS records correctly is not just an IT task; it is a critical business function. This guide provides a thorough, production-ready walkthrough of SPF, DKIM, and DMARC, covering what each does, how to set them up, common mistakes to avoid, and how to monitor them for ongoing security.

What Is SPF?

Sender Policy Framework (SPF) is an email authentication method that specifies which mail servers are authorized to send email on behalf of your domain. It works by publishing a list of approved IP addresses or hostnames in a DNS TXT record. When a receiving mail server gets a message claiming to be from your domain, it checks the SPF record to see if the sending server’s IP is allowed. If the IP is not listed, the email may be rejected, quarantined, or marked as spam, depending on the receiver’s policy.

SPF helps prevent email spoofing, but it has limitations. It only checks the envelope sender domain (the MAIL FROM address), not the visible From: header. This means a spammer could spoof the display name while using a different envelope domain, bypassing SPF. That is why SPF is typically combined with DKIM and DMARC.

How SPF Works Under the Hood

When an email is transmitted via SMTP, the sending server announces the envelope sender (usually the Return-Path). The receiving server performs a DNS lookup for the SPF record of that domain. The record is a TXT record that begins with v=spf1 followed by mechanisms and modifiers. Mechanisms include:

  • ip4 and ip6 – specify exact IP addresses or CIDR ranges allowed to send.
  • include – imports the SPF policy of another domain (commonly used for third-party email services like SendGrid or Mailgun).
  • a and mx – authorize the domain’s A or MX records as senders.
  • exists – checks if a particular domain exists (rarely used).
  • all – qualifier that defines the default action for senders not matched.

The qualifiers can be + (pass), ~ (softfail), - (fail), or ? (neutral). The most secure setup ends with -all to reject all unauthorized senders.

Step-by-Step SPF Configuration

  1. Identify all legitimate email sources for your domain: your own mail server IPs, your email service provider (e.g., Google Workspace, Microsoft 365, Zoho), and any third-party services that send emails (transactional, marketing, etc.).
  2. Log in to your DNS provider (e.g., Cloudflare, AWS Route 53, GoDaddy, Namecheap).
  3. Add a new TXT record for your domain (often the @ record for the root domain).
  4. Craft the value. Example for a domain using Google Workspace and a third-party service:
v=spf1 include:_spf.google.com include:mailgun.org ~all
  • The include mechanism pulls in the SPF policies of Google and Mailgun.
  • Use ~all during initial testing, then switch to -all after verifying no legitimate senders are blocked.
  1. Save and propagate. DNS changes can take up to 48 hours, but often propagate within minutes.
  2. Validate with online tools like MXToolbox or Kitterman’s SPF validator.

Common SPF Pitfalls

  • Too many DNS lookups – The SPF specification limits the total number of DNS lookups (including includes, a, mx, etc.) to 10. Exceeding this causes the SPF check to return a permanent error, often treated as a neutral result. To reduce lookups, consolidate includes or use a flat list of IPs where possible.
  • Using ?all – A neutral qualifier does not enforce authentication; use ~all or -all to provide meaningful policy.
  • Forgetting to update when changing email providers or adding new services. Always review your SPF record after any infrastructure change.
  • Including too many third-party includes without verifying they are necessary.

What Is DKIM?

DomainKeys Identified Mail (DKIM) provides a cryptographic way to verify that an email was not tampered with in transit and that it genuinely came from the claimed domain. DKIM uses a pair of keys: a private key kept secret by the sending mail server and a public key published in a DNS TXT record. When an email is sent, the server signs the message (or specific headers) with the private key. The receiving server fetches the public key from the domain’s DNS and verifies the signature. If the signature matches, the email is considered authenticated.

DKIM is more robust than SPF because it survives email forwarding. SPF can break when a message is forwarded because the envelope sender may change. DKIM, however, signs the original headers and body, so the signature remains valid even after forwarding.

How DKIM Signatures Are Created

When an email is signed, the sending server adds a DKIM-Signature header containing parameters such as the selector (which public key to use), the domain, the signature algorithm (usually rsa-sha256), and the signed fields. The body of the message is hashed and included in the signature. The receiving server extracts the selector from the header, constructs the DNS key name (e.g., default._domainkey.yourdomain.com), and retrieves the public key record. It then recomputes the hash and compares it.

Configuring DKIM: A Practical Guide

  1. Enable DKIM signing in your email platform. Most providers have a settings page to generate keys.
  2. Note the selector. Many platforms use google (for Google Workspace) or default. Providers like Microsoft 365 may use selector1 or selector2.
  3. Copy the public key. It will be a long base64 string.
  4. Add a TXT record to your DNS with the hostname [selector]._domainkey.yourdomain.com and the value provided by your email provider, which typically looks like:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...[truncated]
  • The v=DKIM1 tag indicates the version. k=rsa is the key type (default). p= is the public key data.
  1. Wait for propagation and then test by sending an email and examining the headers for a valid DKIM signature. Tools like mxtoolbox.com or Google’s Postmaster Tools can verify.

DKIM Key Rotation and Security

Best practice is to rotate DKIM keys periodically (e.g., every 6 months). Many email providers automatically handle key rotation. If you manage your own mail server, generate a new key pair regularly and update the DNS record. Keep the private key secure; never expose it publicly.

Also consider using Author Domain Signing Practices (ADSP) to indicate that all emails from your domain should be DKIM-signed. However, ADSP is largely obsolete; DMARC now covers that use case.

What Is DMARC?

Domain-based Message Authentication, Reporting & Conformance (DMARC) unifies SPF and DKIM under a single policy framework. DMARC tells receiving mail servers what to do with messages that fail both SPF and DKIM checks. It also provides a reporting mechanism that gives domain owners visibility into email authentication failures, helping them detect abuse and fine-tune their configurations.

DMARC policy is set in a DNS TXT record under _dmarc.yourdomain.com. The record specifies a policy for how to treat unauthenticated mail: none (monitor only), quarantine (mark as spam), or reject (block delivery).

How DMARC Aligns SPF and DKIM

DMARC introduces the concept of identifier alignment. For SPF to pass DMARC, the domain in the envelope from (or Return-Path) must align with the domain in the visible From: header. For DKIM, the signing domain (the d= parameter in the DKIM-Signature header) must align. Alignment can be strict (exact match) or relaxed (subdomains allowed). You set this via the adkim and aspf tags.

A DMARC check succeeds if at least one of SPF or DKIM passes and aligns with the domain used in the From: header. If both fail, the DMARC policy is enforced.

Configuring DMARC: From Monitoring to Enforcement

  1. Start with a p=none policy. This allows you to collect reports without affecting delivery. Do not skip this step.
  2. Add a report email address using the rua tag (aggregate reports) and optionally ruf (forensic reports). Example:
v=DMARC1; p=none; rua=mailto:[email protected]
  1. Analyze the reports for at least two weeks. Use tools like Postmark’s DMARC Dashboard, DMARCian, or Dmarcian. Look for any legitimate services that are failing authentication and fix them (update SPF, add DKIM signing).
  2. Move to p=quarantine once you are confident no legitimate email is failing. Continue monitoring.
  3. Finally, set p=reject after a month or two of successful quarantine handling. This tells receivers to block all unauthenticated email, providing the strongest protection against spoofing.

DMARC Tags and Options

  • v=DMARC1 – version (mandatory).
  • p= – policy for the organizational domain (none, quarantine, reject).
  • sp= – policy for subdomains (if not set, subdomains inherit p).
  • adkim=s or r – DKIM alignment mode (strict or relaxed).
  • aspf=s or r – SPF alignment mode.
  • rua= – email address(es) for aggregate feedback (usually a mailto: URI).
  • ruf= – email for forensic reports (used for individual failure details).
  • fo= – failure reporting options (e.g., fo=1 to generate reports if any check fails).
  • pct= – percentage of messages to apply policy (use 100 for full enforcement).

DMARC Reporting and Monitoring

Aggregate reports (rua) are XML files sent daily by participating receivers (like Google, Yahoo, Microsoft). They contain counts of messages by source IP, authentication results, and disposition. Forensic reports (ruf) provide details on individual failures. Use these reports to discover unauthorized senders, misconfigured third-party services, or forwarded email that breaks authentication.

Several free and paid tools parse DMARC reports and present them in a readable format. For a hands-on approach, you can set up a report parsing service like dmarcian or use open-source solutions such as parsedmarc.

Putting It All Together: A Cohesive Authentication Strategy

SPF, DKIM, and DMARC work synergistically. SPF prevents unauthorized IPs from sending mail using your domain. DKIM ensures message integrity and provenance. DMARC aligns these two and provides a policy enforcement layer plus visibility. Properly configuring all three yields the highest deliverability and the strongest protection against domain spoofing.

Here is a checklist for a production-grade configuration:

  • SPF: Publish a record that includes all legitimate sending sources, respects the 10-lookup limit, and ends with -all (after testing).
  • DKIM: Sign all outgoing emails with at least one selector. Rotate keys regularly. Ensure your email platform signs transactional and marketing emails.
  • DMARC: Start with p=none, analyze reports, then progress to p=quarantine and finally p=reject. Set alignment to relaxed unless you have strict requirements.
  • Monitor continuously: Regularly check DMARC reports, especially after adding new email services. Adjust records as needed.

Real-World Example: Configuring for Directus

If you host a Directus instance and send emails (e.g., password resets, notifications), you need to authenticate those messages. Assume your Directus app uses an SMTP service like SendGrid or Mailgun. Follow these steps:

  1. Obtain the sending IPs or include domain from your SMTP provider (e.g., include:sendgrid.net for SendGrid).
  2. Add that to your SPF record. If you also send from another system (e.g., a PHP mail server), include its IPs as well.
  3. Generate DKIM keys in your SMTP provider’s dashboard and publish the public key.
  4. Set up a DMARC record with p=none pointing to a monitored email address.
  5. Test by sending a test email from Directus to a mailbox like Gmail and inspect the authentication headers.

Troubleshooting Common Issues

SPF PermError: Too Many Lookups

If your SPF record includes multiple include: statements, you may exceed 10 DNS lookups. To fix, either remove unnecessary includes, combine them using IP ranges, or create a subdomain with a leaner SPF record.

DKIM Signature Missing or Failing

Check that the private key is correctly installed on the sending server. For shared email providers, ensure DKIM signing is enabled in the control panel. Verify that the selector in the DNS TXT record matches the selector in the email header.

DMARC Reports Show Failures for Legitimate Email

Common causes: forwarded email (SPF fails because the forwarder changes the envelope), third-party services not DKIM-signing, or alignment mismatch. For forwarded email, consider using ARC (Authenticated Received Chain) if supported, or instruct recipients to whitelist. For third-party services, add DKIM signing and ensure SPF includes their servers.

External Resources and References

For deeper dives, refer to these authoritative sources:

Final Thoughts

Configuring SPF, DKIM, and DMARC is not a one-time task but an ongoing process. Email authentication landscapes evolve, and so do threats. By setting up these records correctly and monitoring them continuously, you protect your domain, improve deliverability, and build trust with your recipients. Start with a careful audit of your email sending infrastructure, implement the records one by one, and never skip the reporting phase. Your domain — and your business — will be more secure as a result.