Learn SPF, DKIM and DMARC: Protect Your Domain Against Email Spoofing

Email spoofing is a serious threat that allows attackers to send fake emails from your domain. It can lead to phishing, data breaches and reputational damage, all without your knowledge. If your domain isn’t properly secured, it could be used as a tool in cybercrime.

SPF, DKIM and DMARC are powerful email authentication protocols that help prevent this. In this article, you'll learn what they are, how they work together and how to implement them to protect your domain from abuse.

Sender Policy Framework (SPF) #

SPF is an email authentication mechanism designed to detect and prevent email spoofing. It allows domain owners to specify which mail servers are authorised to send email on behalf of their domain. Receiving mail servers use the SPF policy to verify the sender's IP address against this list.

Purpose #

• Prevent spammers from sending unauthorised emails that appear to come from your domain.
• Reduce the likelihood of legitimate emails being marked as spam by enabling recipients to verify authenticity.
• Enhance domain reputation and email deliverability.

How SPF Works #

1. The domain owner publishes an SPF record in the DNS.
2. When an email is received, the recipient's mail server:
   • Extracts the domain from the "MAIL FROM" (envelope sender).
   • Retrieves the SPF record from DNS.
   • Checks if the sending server's IP is listed as authorised.
3. Based on the result, the recipient server decides to accept, flag, or reject the message.

SPF Record Format #

SPF records are stored as DNS TXT records. A basic example:

v=spf1 ip4:192.0.2.10 include:_spf.example.com -all

Explanation of Components:

Qualifiers:

Common Mechanisms:

Example Use Cases #

Basic SPF for a single server:

v=spf1 ip4:203.0.113.5 -all

• Only one server is allowed to send mail.
• All others fail.

Including Google Workspace:

v=spf1 include:_spf.google.com ~all

• Delegates SPF checks to Google's SPF record.
• Messages not passing the check are soft-failed.

Authorising multiple servers and providers:

v=spf1 ip4:192.0.2.1 include:_spf.example.com include:_spf.sendgrid.net -all

• Combines in-house servers and third-party provider authorisation.

DNS and SPF Limits #

SPF lookups and mechanisms have specific limitations:

• 10 DNS Lookup Limit: Includes include, a, mx, ptr, and exists.
• 255-character limit: TXT records exceeding this must be split across multiple quoted strings.
• Redirects: Only one redirect= allowed per SPF record.

Exceeding lookup limits results in PermError during evaluation, causing SPF to fail.

SPF Evaluation Results #

Best Practices #

• Always end SPF records with -all or ~all.
• Avoid using +all as it defeats the purpose of SPF.
• Regularly review and update SPF records to reflect infrastructure changes.
• Minimise DNS lookups to stay within the 10-lookup limit.
• Use include: carefully to avoid unintentional trust of third-party records.

Validation #

dig +short TXT example.com

DomainKeys Identified Mail (DKIM) #

DKIM is an email authentication mechanism that allows the recipient to verify that an email was genuinely sent by the domain it claims to come from and that it was not tampered with in transit.

It uses public-key cryptography to sign outgoing email headers and content, which receiving mail servers can validate using DNS.

Purpose #

• Prove that an email was sent by an authorised source (domain-level authentication).
• Ensure that the message content has not been modified after it was sent.
• Help receiving mail servers assess whether an email is legitimate and trustworthy.
• Work with SPF and DMARC to enhance email security and deliverability.

How DKIM Works #

1. The sending mail server signs email headers (and optionally body) using a private key.
2. The public key is published as a DNS TXT record under a specific selector.
3. The receiving server:
   • Extracts the DKIM signature from the email.
   • Retrieves the public key via DNS.
   • Uses it to verify that the message signature is valid and matches the message content.

Components of DKIM #

1. DKIM-Signature Header

This header is added to outgoing emails and contains:

• Signing domain (d=).
• Selector (s=).
• Signed headers (h=).
• Hash algorithm (a=).
• Body hash (bh=).
• Signature data (b=).

Example header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
 c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
 bh=...; b=...

2. DNS TXT Record

The DKIM public key is stored in DNS under:

<selector>._domainkey.<domain>

Example DNS record for selector = mail and domain = example.com:

mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G...AB"

• v=DKIM1 specifies the DKIM version.
• k=rsa specifies the key type.
• p= is the Base64-encoded public key.

DKIM Signature Parameters #

Canonicalisation #

• Simple: Requires exact match between sent and received email.
• Relaxed: Ignores insignificant formatting (e.g. extra spaces or line breaks).

Key Management #

• Use a key size of at least 1024 bits (2048 bits recommended for security).
• Rotate DKIM keys periodically to maintain security.
• Different selectors can be used for key rotation without downtime.

Deployment Steps #

1. Generate a DKIM key pair (private and public).
2. Configure your mail server to sign emails using the private key and appropriate selector.
3. Publish the public key as a TXT record in DNS under:
   <selector>._domainkey.<yourdomain>
4. Send test emails and validate DKIM headers.

DKIM Evaluation Results #

Best Practices #

• Use 2048-bit RSA keys for improved security.
• Rotate DKIM keys at regular intervals (e.g. every 6–12 months).
• Use meaningful selector names (e.g. mail2024, smtp1, etc).
• Include all relevant headers in the DKIM signature.
• Combine DKIM with SPF and DMARC for comprehensive protection.

Validation #

dig +short TXT mail._domainkey.example.com

Domain-based Message Authentication, Reporting & Conformance (DMARC) #

DMARC is an email authentication protocol that builds on SPF and DKIM to provide domain owners with the ability to:

• Publish policies on how unauthenticated messages should be handled (none, quarantine, or reject).
• Receive reports about email messages using their domain.
• Protect their domain from spoofing, phishing, and unauthorised use.

Purpose #

• Prevent unauthorised senders from spoofing your domain.
• Improve visibility into how your domain is being used via aggregate and forensic reports.
• Define actions for receivers to take when SPF or DKIM fails.
• Increase email trustworthiness and deliverability.

How DMARC Works #

1. Domain owner publishes a DMARC policy in DNS.
2. Recipient mail servers perform SPF and DKIM checks on incoming mail.
3. DMARC checks if the email passes:
   • SPF or DKIM, and
   • Alignment with the domain in the "From" header.
4. Based on the DMARC policy, the receiving server takes action:
   • Allow the mail (none),
   • Mark it as spam (quarantine),
   • Reject it outright (reject).
5. If reporting is enabled, aggregate and/or forensic reports are sent back to the domain owner.

DMARC Policy Syntax #

DMARC is defined via a DNS TXT record at:

_dmarc.<yourdomain>

Example:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100

DMARC Tag Reference #

Policy Options #

SPF/DKIM Alignment #

DMARC requires alignment between the domain in the From header and the domain used in SPF/DKIM.

• Strict (s): Domains must be an exact match.
• Relaxed (r): Subdomains are allowed to match.

Example:

• From: [email protected]
• SPF result for mail.example.com → passes under relaxed alignment, fails under strict.

DMARC Reporting #

Aggregate Reports (rua)

• XML format
• Daily summary from receivers
• Includes sending IPs, counts, SPF/DKIM results

Forensic Reports (ruf)

• Optional
• Include redacted copies of failed emails
• Sent in real time
• Higher privacy risk, often not supported by all providers

Example Record with Reporting

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Deployment Strategy #

• Start with p=none to collect reports and assess impact.
• Monitor aggregate reports for at least 1–2 weeks.
• Move to p=quarantine, then to p=reject once authorised senders are confirmed.
• Set pct to a lower value (e.g. 10 or 25) during gradual enforcement.
• Rotate and review reports regularly to ensure policy remains accurate.

Best Practices #

• Ensure all legitimate email sources are configured with correct SPF and DKIM.
• Use rua for visibility into domain usage.
• Avoid forensic reporting (ruf) unless necessary and legally compliant.
• Gradually transition from none to reject.
• Monitor reporting inboxes and act on anomalies.

Validation #

dig +short TXT _dmarc.example.com

Next Steps #

Implement #

Read guides:

• Step-by-Step Guide: Securing Unused or Parked Domains from Spoofing and Abuse
• Step-by-Step Guide: Securing Your Domain from Email Spoofing and Abuse