An authorized server can send an unwanted message. A valid signature can belong to a domain different from the one shown to the recipient. Each check answers a different question about the message.
What does each check prove?
SPF checks the sending IP, DKIM checks a signature, and DMARC connects a passing result to the visible From domain.
| Check | Identity checked | What a pass establishes | What it does not establish |
|---|---|---|---|
| SPF | Envelope-from domain, normally used for bounces | The connecting IP is authorized by that domain's policy. | The visible From domain or the message's integrity. |
| DKIM | Signing domain in the signature's d= value | The signature verifies against its published key and signed content. | That every part of the message was signed or that recipients want it. |
| DMARC | Visible From domain | At least one passing SPF or DKIM result aligns with that domain. | Guaranteed delivery or inbox placement. |
How does SPF work?
The receiver compares the connecting server's IP with the SPF policy published in DNS for the envelope-from domain. It can make that check before receiving the message body, because SPF does not examine the content.
- You publish the servers or services authorized to use that domain.
- The receiver looks up the policy and evaluates its rules against the connecting IP.
- The receiver uses the result alongside its own acceptance and filtering policy.
If an alumni mailbox forwards a message to another provider without changing the envelope-from address, the forwarding IP may lack authorization. A mailing list can produce the same problem when it resends a message. A forwarder can use Sender Rewriting Scheme (SRS), which changes the envelope-from address to a domain it can authenticate.
An SPF record specifies authorized senders. Nested provider policies count toward the DNS lookup limit.
How does DKIM work?
Your sending server signs message content with a private key. The receiver uses the corresponding public key in DNS to verify that signature.
The signature identifies the signing domain with d= and the key selector with s=. The selector identifies which DNS record contains the public key. The receiver looks up the public key and verifies the signature using that domain and selector.
Forwarding alone does not invalidate DKIM, because the check does not depend on the forwarding server's IP. Changing signed content, such as adding a mailing-list footer, can invalidate the signature. The signature authenticates the content it covers; it does not encrypt the message.
How does DMARC connect the identities?
DMARC requires a passing SPF or DKIM result whose domain aligns with the visible From domain. Either aligned pass is sufficient.
For example, a message showing From: billing@example.com can pass SPF for send.example.com under relaxed alignment. A passing DKIM signature with d=example.com also aligns. Authentication for unrelated.example does not align with example.com merely because it passes.
You publish a DMARC policy to request handling of failing messages and authentication reports. Participating receivers supply reports; their absence does not prove that no mail used your domain.
What should you configure for Bird?
You publish DKIM, the return-path CNAME and DMARC for your sending domain. The return-path CNAME points to Bird's bounce infrastructure, which provides SPF authorization without an extra apex SPF record.
Copy the records from dns_records. Check capabilities.sending.status for sending readiness. Its values identify what you need to do next:
| Status | Meaning and action |
|---|---|
pending | Verification has not run or is running; wait for its result. |
verified | The capability's DNS records match the expected values. |
warning | Previously verified records no longer match; fix them before the grace period ends. Sending is not yet affected. |
failed | A DNS value is wrong; correct it. |
temporary_failure | A DNS lookup failed transiently; verification retries automatically. |
not_configured | The capability is not set up for this domain. |
You publish the authentication records and verify your sending domain.
Which checks should you use?
Use SPF and DKIM with DMARC so the authenticated identities connect to the domain your recipients see.
- Authorize the envelope-from domain's sending infrastructure with SPF.
- Sign outgoing messages with DKIM and publish the verification key.
- Publish DMARC, review reported authentication failures and correct legitimate senders before enforcing quarantine or rejection.