SPF, DKIM, and DMARC Explained for Developers

SPF, DKIM, and DMARC are the three email authentication records every developer meets when sending from a custom domain. They can look like DNS trivia at first, but they decide whether Gmail, Outlook, and other providers trust your messages.

If your application sends password resets, receipts, login codes, or security alerts, authentication is not optional. A great API call will not help if the receiving server thinks your domain is being spoofed.

SPF: Who Is Allowed to Send

SPF stands for Sender Policy Framework. It is a DNS TXT record that says which services are allowed to send mail for your domain. When a receiving server gets a message, it can check the sending server against the SPF policy published by the domain.

example.com.  TXT  "v=spf1 include:spf.zidimails.com -all"

The exact include value depends on your provider. The important idea is that SPF authorizes sending infrastructure. If your domain has no SPF record, or the record does not include the service actually sending the message, receivers may treat the email as suspicious.

DKIM: Did the Message Change

DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to each message. The public key lives in DNS, and the private key is used by the sending service. Receivers verify the signature to confirm that the message was authorized by the domain and was not modified in transit.

zidimail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

DKIM is especially important for forwarding and modern deliverability checks. It gives receivers a stronger signal than SPF alone because it signs the message itself.

DMARC: What Receivers Should Do

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It tells receivers what to do when SPF or DKIM checks fail, and it lets domain owners request reports. DMARC also introduces alignment: the domain visible to the user should align with the authenticated domain.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

A DMARC policy can be relaxed during setup and stricter later. Many teams start with p=none for monitoring, move to quarantine, and eventually use reject once they are confident all legitimate senders are covered.

Why Gmail and Outlook Care

Mailbox providers fight phishing at enormous scale. Attackers love pretending to send from trusted domains. SPF, DKIM, and DMARC give receivers a way to distinguish legitimate product email from spoofed messages. Without them, your domain looks risky, especially when sending at production volume.

Common Developer Mistakes

• Adding multiple SPF TXT records instead of one combined SPF policy.
• Copying DNS records with extra quotes or missing selector names.
• Forgetting that DNS changes can take time to propagate.
• Sending from a domain before verification is complete.
• Using strict DMARC before all legitimate senders are configured.

How ZidiMail Helps

ZidiMail walks you through the DNS records needed to send from your own domain. Instead of guessing which SPF include, DKIM selector, or DMARC value to publish, you can follow the domain setup flow and verify the records before sending production traffic.

Read the ZidiMail docs when you are ready to connect a domain. Once authentication is in place, your transactional email has a much stronger foundation for inbox placement.

How to Roll Out DMARC Safely

The safest DMARC rollout is gradual. Start by identifying every service that sends email for your domain: your transactional provider, help desk, billing system, calendar tool, and any internal automation. If one legitimate sender is missing from SPF or DKIM, a strict DMARC policy can block mail you actually want to deliver.

Many teams begin with p=none so they can collect reports without changing delivery behavior. After the reports show that legitimate mail is authenticated, move to quarantine for a portion of traffic. Once you are confident, use reject to tell receivers that unauthenticated mail should not be accepted.

For developers, the main lesson is to treat DNS records as part of the deployment checklist. Do not merge a new sending provider into production until the domain passes authentication checks. ZidiMail keeps that setup visible so you can verify the records before relying on them for user-facing email.

You should also document who owns the records. DNS changes often sit between engineering, IT, and security teams. A short note explaining each record, the provider it belongs to, and the date it was added can save hours later when someone audits the domain or removes an old service.