How SPF works
Sender Policy Framework allows a domain owner to publish which systems are permitted to send using a particular envelope domain. The receiving server checks the connecting source against that published policy.
SPF is evaluated against the envelope identity rather than simply the From address a person sees. Forwarding can also complicate SPF because the forwarding server may not be included in the original sender's policy.
Important SPF constraints
- A domain should publish a single effective SPF record rather than separate competing records.
- SPF processing has a limit on mechanisms that cause DNS lookups. Large chains of included services require careful management.
- Removing an old service matters because an unnecessary include can leave authorisation wider than intended.
How DKIM works
DomainKeys Identified Mail adds a cryptographic signature to a message. A receiving system retrieves the public key from DNS and verifies the canonicalised signed headers and body. Relaxed canonicalisation can tolerate specific presentation changes, such as defined whitespace changes, without invalidating the signature.
The signature identifies a signing domain and selector. Selectors allow keys to be rotated and enable different services to sign independently. Key management and rotation remain the sender's responsibility even when a provider automates setup.
How SPF, DKIM and DMARC work together
| Method | Primary question | Important limitation |
|---|---|---|
| SPF | Is this sending source authorised for the envelope domain? | Forwarding and domain alignment can affect results. |
| DKIM | Does this message carry a valid signature for the signing domain? | A valid signature is only useful to DMARC when the domain aligns. |
| DMARC | Does aligned SPF or DKIM pass for the visible From domain? | It needs accurate SPF or DKIM foundations and ongoing monitoring. |
Common configuration mistakes
- Publishing multiple SPF records for the same hostname.
- Authorising a platform that is no longer used.
- Adding services without checking the cumulative DNS lookup path.
- Enabling DKIM in DNS but not in the sending platform, or the reverse.
- Assuming a passing authentication result automatically means DMARC alignment.
- Moving directly to a strict DMARC policy before discovering every legitimate sender.
Questions for a configuration review
- Which platforms send as the main domain or its subdomains?
- Who owns each platform and can confirm whether it remains active?
- Which domain does each service use for the envelope identity?
- Which domain signs DKIM, and are keys current?
- Does at least one passing method align with the visible From address?
- How will changes be monitored and rolled back?
Do not copy another organisation's DNS records
Authentication records describe your services, domains and keys. Use the exact values generated for your own account and verify them with the relevant provider.