Set up email authentication with SPF, DKIM, and DMARC

Receiving mail systems no longer give unauthenticated email the benefit of the doubt — the large mailbox providers now expect SPF, DKIM, and DMARC as a baseline, especially from bulk senders. Authentication won’t guarantee the inbox, but getting it wrong (or skipping it) invites rejections, spam-folder placement, and spoofing of your domain.

1. Inventory every sender

List the primary mail provider, marketing platform, support system, CRM, transactional service, website forms, monitoring alerts, invoices, and any server that sends mail using the domain. Include subdomains and forwarding paths.

Don’t publish a policy until this inventory has an owner. Nearly every “DMARC broke our invoices” story traces back to a sender someone forgot — it’s always the billing tool set up three years ago that gets missed.

2. Publish one SPF record

SPF is a TXT record that authorizes systems to use the envelope-from domain. Use the exact mechanisms supplied by each provider. A simple provider-specific record might look like:

v=spf1 include:_spf.mail-provider.example ~all

Publish only one SPF record per hostname. Combine authorized sources into that policy and remain within SPF’s DNS-lookup limit. Remove retired senders. Google’s SPF setup guide recommends inventorying all senders before adding the record.

3. Enable DKIM signing

Generate a DKIM key in the sending platform. Publish the provided public key at the selector hostname, commonly:

selector1._domainkey.example.com

Then enable signing in the provider. Verify a delivered message has a valid DKIM signature whose d= domain aligns with the visible From domain. Prefer current provider guidance on key length and rotation. Keep the private key in the sending system, never DNS.

4. Add DMARC reporting first

DMARC is published at _dmarc.example.com. Begin with monitoring and an aggregate-report mailbox prepared to receive or process reports:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

DMARC passes when an aligned SPF or DKIM identity passes. Reports reveal legitimate and unauthorized sources but can contain operational data; handle them under the organization’s privacy and retention policies.

5. Fix alignment and exceptions

Review reports over a representative business cycle. Configure third-party services to sign with the organization’s domain or use an aligned envelope-from domain. Investigate forwarding and mailing-list behavior, where SPF may fail but aligned DKIM can still pass.

Test real messages to several receiving providers and inspect full headers.

6. Increase enforcement gradually

After legitimate sources pass, move from p=none to a limited quarantine policy, then toward broader quarantine or rejection according to risk tolerance. Use pct only with a clear rollout plan and understand subdomain policy before setting sp=.

Keep reports active and maintain a change process: no new sender may use the domain until authentication and alignment are verified.

Sources and further reading

• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 7489: DMARC