Email Security: SPF, DKIM and DMARC in Five Steps

SPF alone says nothing about the visible sender address (RFC 7208, Section 11.2). Only DMARC links them: a message passes DMARC if at least one domain verified by SPF or DKIM aligns with the sender domain (RFC 9989, Section 5.3.5).

Record every service that sends emails with your domain as the sender. Every legitimate sender will later need a passing SPF or DKIM result with an aligned domain; gaps must be closed before you publish a strict policy (RFC 9989, Section 5.1.6).

• Your own mail server or Microsoft 365 or Exchange Online
• Newsletter and marketing services
• CRM, ticket system, web shop and accounting (invoice delivery)
• Devices and applications that send via SMTP, such as scanners, monitoring and web forms
• Service providers that send on your behalf
• Domains and subdomains that do not send any email at all

; Microsoft 365 and your own server (192.0.2.25 is an example address)
example.com.      IN TXT "v=spf1 ip4:192.0.2.25 include:spf.protection.outlook.com -all"

; Name under which no email is sent
www.example.com.  IN TXT "v=spf1 -all"

• Exactly one SPF entry per domain: multiple entries with v=spf1 result in a permanent error (permerror, RFC 7208, Section 4.5).
• No more than 10 DNS lookups caused by include, a, mx, ptr, exists and redirect during the entire evaluation, otherwise permerror (Section 4.6.4). The entries of included service providers count too.
• Do not use ptr (Section 5.5).
• -all (fail) explicitly declares servers not listed as unauthorized, ~all (softfail) is only a weak statement; recipients should not reject on the basis of softfail alone (Sections 2.6.4, 2.6.5 and 8.5).
• Names that do not send email publish v=spf1 -all (Section 10.1.2).
• A TXT string holds no more than 255 characters. Longer entries are split into several strings, which the recipient concatenates without spaces (Section 3.3).

Each sender signs with its own key. You publish the public key as a TXT entry under <selector>._domainkey.<domain>; the selector (s=) and domain (d=) appear in the signature of every message (RFC 6376, Sections 3.5 and 3.6.2.1).

mail2026._domainkey.example.com.  IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

• Sign only with rsa-sha256; rsa-sha1 must not be used for signing or verifying (RFC 8301, Section 3.1).
• Keys of at least 1024 bits, 2048 bits recommended (RFC 8301, Section 3.2).
• Microsoft 365: DKIM is set up via two CNAME entries selector1._domainkey and selector2._domainkey; Get-DkimSigningConfig shows the exact targets. When created via PowerShell, 1024 bits is the default; Rotate-DkimSigningConfig -KeySize 2048 switches to 2048 bits.
• DKIM signatures usually survive forwarding, SPF does not. Anyone who publishes p=reject therefore must not rely on SPF alone and must sign validly with DKIM (RFC 9989, Section 7.4).

_dmarc.example.com.  IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-berichte@example.com"

• p=none expresses no preference for handling failures (monitoring mode). With rua, you receive aggregate reports on all servers that send with your domain (RFC 9989, Sections 5.1.4 and 5.1.5).
• The reports are intended for automated processing; use an analysis tool or service (Section 5.1.5).
• If the report mailbox is in a different domain, that domain must consent, for example with a TXT entry example.com._report._dmarc.example.net containing v=DMARC1 (RFC 9990).
• Failure reports (ruf) contain content from individual messages; most recipients do not send them for privacy reasons (RFC 9989, Section 10.2). Aggregate reports remain the recommended means (RFC 9991).
• Every legitimate sender without aligned SPF or DKIM is fixed before a strict policy applies (RFC 9989, Section 5.1.6).

• t=y marks a policy in testing: recipients apply one level less, so for p=reject only quarantine (RFC 9989, tag t). The former pct tag no longer exists since RFC 9989; older guides, including Microsoft’s, still mention it.
• Subdomains: sp applies to existing subdomains, np to non-existent ones; if both are missing, p applies (RFC 9989, tags sp and np).
• Mailing lists: according to RFC 9989, domains whose users post to mailing lists on the internet should not publish p=reject; anyone who does so anyway should inform users that participation in mailing lists may be impaired (Section 7.4).

parked.example.com.         IN TXT "v=spf1 -all"
_dmarc.parked.example.com.  IN TXT "v=DMARC1; p=reject;"
parked.example.com.         IN MX  0 .

The null MX entry MX 0 . states that the domain does not accept email; there must be no other MX entry alongside it, and domains used as senders should not publish it (RFC 7505). For unused domains, Microsoft recommends DMARC entries stating that no email may ever come from them, and no DKIM entries.

• All senders are recorded, including external services and devices.
• Exactly one SPF entry, no more than 10 DNS lookups, ending with -all or ~all.
• DKIM for every sender with rsa-sha256 and a 2048-bit key.
• DMARC with p=none and rua; the reports are evaluated.
• All legitimate senders pass DMARC with an aligned domain.
• p=quarantine, then p=reject; mailing lists are taken into account.
• Domains without email traffic are secured with SPF, DMARC and null MX.