Email Authentication Checklist: SPF, DKIM, DMARC, and Alignment

Email authentication is the part of deliverability that should be boring. You publish the right DNS records, sign messages correctly, check alignment, and keep an inventory of every service allowed to send as your domain.

It becomes dangerous when a team treats a green “verified” badge in an email platform as proof that every message is authenticated. A domain can be verified for one stream while another service still fails DKIM, an SPF record can contain the wrong sender, and DMARC can pass or fail depending on alignment with the visible From domain.

This checklist is written for a founder, marketer, or developer setting up a sending domain. It explains what to collect, what each record does, how to validate it, and how to roll out enforcement safely.

The checklist at a glance

Google’s Email sender guidelines require SPF or DKIM for all senders to Gmail personal accounts, and higher-volume senders must use SPF, DKIM, and DMARC with alignment. Requirements differ by mailbox provider, but the direction is consistent: authenticated, aligned mail is the baseline.

Before you touch DNS

Create a sending inventory first. List every service that sends mail for your domain:

• Marketing campaigns and newsletters.
• Transactional messages such as receipts, alerts, and password resets.
• Customer support or ticketing systems.
• Billing and payment providers.
• Product notifications and internal tools.
• Forms, scheduling tools, and sales automation.
• The return-path or bounce domain used by each service.

For each service, record the visible From domain, envelope or return-path domain, DKIM selector, SPF include, and whether the service supports a custom tracking or sending domain. This inventory is more valuable than copying a generic SPF record because it prevents you from forgetting a legitimate stream when you tighten DMARC later.

Step 1: Publish one correct SPF record

SPF is a DNS policy that tells receivers which sending infrastructure may use a domain in the SMTP envelope. It does not authenticate the visible From header by itself, and it does not sign the message.

The key SPF rules are operational rather than mysterious:

• Publish one SPF TXT record per domain. Multiple SPF records cause a permanent error.
• Include every legitimate sender that uses the domain.
• Remove services that no longer send mail.
• Stay within SPF’s DNS lookup limit; nested includes can consume it quickly.
• Avoid treating an SPF “pass” as the same thing as DMARC pass. Alignment still matters.

An illustrative record looks like this:

example.com.  TXT  "v=spf1 include:provider.example include:billing.example ~all"

Use the exact include value supplied by each provider. Do not copy the example into production, and do not add a sender just because it appears in an old setup document.

Step 2: Turn on DKIM for every sending stream

DKIM adds a cryptographic signature to outgoing messages. The provider keeps the private key; you publish the matching public key at a selector host in DNS.

An illustrative record looks like this:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_PROVIDER"

The exact selector and record value come from the provider. A successful domain-verification step is not enough if a different provider sends from the same visible From domain without its own DKIM configuration.

Check that:

• The selector host is spelled exactly as supplied.
• The public key is complete and has not been wrapped or truncated incorrectly.
• The message’s d= signing domain is the domain you expect.
• DKIM passes on a real message sent through the actual production path.
• Every vendor that sends mail has a documented selector or an explicit reason it cannot use one.

Step 3: Publish DMARC with reporting

DMARC tells receivers what to do with mail that fails authentication and alignment, and where to send aggregate reports. It is published at _dmarc on the organizational domain or relevant subdomain.

Start with a monitoring record that does not request a delivery action:

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

After you have reviewed the reports and fixed legitimate failures, move to a stronger policy:

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

Eventually, a mature setup may use:

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

These are examples, not copy-and-paste defaults. Make sure the report destination is monitored, the domain is authorized to receive reports when using a third-party mailbox, and every legitimate mail stream is represented in the data before enforcement.

Step 4: Check alignment, not just authentication

DMARC can pass when either SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From header.

Do not assume that using a friendly From address means the provider is signing for that domain. Inspect the headers of a message delivered to a test mailbox and look at Authentication-Results, DKIM-Signature, and the envelope sender.

Step 5: Validate with DNS and a real message

Use DNS tools to verify that records are visible:

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Then send a real message through each production sender to test mailboxes at Gmail, Outlook, and another provider used by your audience. Inspect:

• SPF result and the domain that was evaluated.
• DKIM result and the signing domain.
• DMARC result and the aligned identifier.
• Return-path and visible From domain.
• Whether links, images, and tracking domains use the expected brand domain.

DNS lookup success only proves that the record exists. Header inspection proves that your actual message used it.

Step 6: Roll out enforcement gradually

The DMARC deployment guidance from dmarc.org recommends starting with SPF and DKIM, checking alignment, publishing p=none, analyzing reports, and moving toward quarantine and reject as confidence grows. Google’s recommended DMARC rollout likewise advises setting up SPF and DKIM first and monitoring before enforcement.

A practical rollout looks like this:

The timeline depends on how many vendors and subdomains you operate. Do not move because a calendar says it is time; move when the reports and message tests support it.

Common failure modes

Two SPF records

Symptom: SPF returns a permanent error or behaves unpredictably.

Fix: Combine the legitimate mechanisms into one SPF record and remove the duplicate. Keep an inventory so the cleanup does not remove an active sender.

DKIM is published for the wrong selector

Symptom: DNS has a public key, but the message says dkim=fail.

Fix: Compare the selector in the actual DKIM-Signature header with the DNS host. Providers often use different selectors across accounts or environments.

DMARC fails even though SPF passes

Symptom: spf=pass but dmarc=fail.

Fix: Check whether the SPF-authenticated envelope domain aligns with the visible From domain. If not, use an aligned DKIM signature or configure a custom return-path.

A new tool breaks DMARC later

Symptom: A new billing, support, or sales tool starts appearing in aggregate reports as a failure.

Fix: Add domain authentication to the launch checklist. Do not wait for a delivery incident to discover that a vendor sends as your brand.

Authentication passes but mail still lands in spam

Symptom: SPF, DKIM, and DMARC pass, but placement is poor.

Fix: Authentication proves identity and policy alignment; it does not guarantee inbox placement. Review consent, complaints, content, engagement, list hygiene, and sending reputation.

How Sequenzy fits

Sequenzy can help centralize marketing and transactional email while keeping domain verification and deliverability checks visible. Use deliverability as part of setup, keep transactional and marketing streams intentional, and validate the domain with real messages before scaling volume.

The platform cannot fix a forgotten vendor, a duplicate SPF record, or a broken DNS change outside your account. Authentication is an operating process, not a one-time checkbox.

FAQ

Do I need SPF, DKIM, and DMARC for low-volume sending?

SPF or DKIM is the baseline for sending to Gmail personal accounts, but configuring SPF, DKIM, and DMARC early is safer than adding them after a reputation problem. A monitoring-only DMARC policy gives you visibility without asking receivers to quarantine or reject failures.

Can I publish more than one SPF record?

No. A domain should have one SPF policy record. Add legitimate providers to the same record and watch the DNS lookup limit.

Does DMARC replace SPF or DKIM?

No. DMARC depends on SPF and/or DKIM authentication and adds alignment plus a policy and reporting layer. Publish and test the underlying mechanisms first.

Is DMARC p=reject guaranteed to block spoofed mail?

It requests rejection of mail that fails DMARC, but receivers retain local policy and can treat messages differently. It is still the strongest policy a domain owner can publish for unauthorized, non-aligned mail.

How often should I review DMARC reports?

Review them at least during every rollout and whenever you add or remove a sender. Mature teams also monitor them continuously or on a regular operational cadence so forgotten vendors do not quietly accumulate.