Email Authentication: SPF, DKIM, DMARC Rollout

Prerequisites#

Before starting, confirm the following:

• You have DNS access to the target domain's zone (Cloudflare dashboard)
• You know what actually sends mail for this domain: a Google Workspace mailbox, Resend transactional mail, or nothing at all
• The DMARC report inbox dmarc@valkyrienexus.com is a real, monitored Google Workspace mailbox or group (if it bounces, every provider's reports are lost silently)
• dig is available on your local machine
• You have an Outlook or Hotmail address available for the final delivery test

Warning: The original trigger for this rollout was sales@stonefyr.com landing in Hotmail/Outlook junk. Root cause was no SPF and no DMARC, and Outlook weights both heavily, so DKIM alone was not enough. Treat all three records as a set.

Step 1: Identify the Sender Profile#

Match the records to the actual sender. Never copy records from another domain just because they look right there, the three profiles publish deliberately different SPF.

Profile	SPF at root @	DKIM selector	Examples
Google Workspace mailbox	v=spf1 include:_spf.google.com ~all	google._domainkey	stonefyr.com, airassaultfireworks.com, valkyrienexus.com
Resend transactional	root SPF intentionally absent	resend._domainkey	mattsdeliciousmeat.com, arnoldsappliancerepair.com
Non-sending / brand-only	v=spf1 -all	none	valkyrienexus.dev

The Resend row is the one that confuses audits. Resend mail authenticates via the send. subdomain: a TXT record at send.<domain> containing v=spf1 include:amazonses.com ~all, plus an MX at send.<domain> pointing to feedback-smtp.<region>.amazonses.com. SPF is checked against that return-path, not the root, so "root SPF missing" on a Resend-only domain is correct, not a bug. Do not "fix" it.

Verify: You can name the sender for this domain in one sentence before touching DNS. If you cannot, find out first.

Step 2: Publish or Edit the SPF Record#

A domain may carry only one SPF record. If a v=spf1 TXT already exists at the root, edit it, never add a second, two SPF records means SPF fails outright.

For a Google Workspace domain, the root TXT is:

v=spf1 include:_spf.google.com ~all

For a brand-only domain that never sends, hard-deny everything:

v=spf1 -all

For a Resend domain, leave the root alone and confirm the send. subdomain records from Step 1 exist (these are normally created when the domain is added in Resend).

All TXT records must be DNS only in Cloudflare. TXT records cannot be proxied.

Verify:

DOMAIN=stonefyr.com
dig +short TXT "$DOMAIN" | grep -i 'v=spf1'

Expected: exactly one v=spf1 line for Google Workspace or brand-only domains, and none for a Resend-only domain.

Step 3: Publish the DKIM Key#

Publish the selector record the sending provider supplies:

• Google Workspace: TXT at google._domainkey.<domain> with the key generated in the Workspace admin console
• Resend: TXT at resend._domainkey.<domain> with the key from the Resend dashboard
• Non-sending domains: no DKIM record at all

Again, DNS only, never proxied.

Verify:

DOMAIN=stonefyr.com
dig +short TXT google._domainkey."$DOMAIN" | head -c40

Expected: the start of a DKIM key. For a Resend domain, query resend._domainkey instead.

Step 4: Publish DMARC at p=none#

Start every domain at the monitoring rung of the ladder. The record lives at the TXT name _dmarc.<domain>, and the name must be exact. A _dmard typo silently disables the entire policy with no error anywhere, it happened on valkyrienexus.dev and only a dig caught it.

v=DMARC1; p=none; rua=mailto:dmarc@valkyrienexus.com; fo=1

fo=1 asks providers for a failure report when either SPF or DKIM fails alignment, instead of only when both do -- more signal during the monitoring phase. The alignment tags are a per-domain choice: stonefyr.com runs strict alignment (adkim=s; aspf=s) because exactly one system sends as that domain, while mattsdeliciousmeat.com stays relaxed (adkim=r; aspf=r) since its mail authenticates via the send. subdomain return-path. When in doubt start relaxed; tighten to strict only after the reports show every legitimate source aligning exactly.

Same rule as SPF: only one DMARC record per domain. Edit the existing one, never add a second.

Verify:

DOMAIN=stonefyr.com
dig +short TXT "_dmarc.$DOMAIN"

Expected: one line starting v=DMARC1 containing a rua= address. If the dig returns nothing, check the record name character by character.

Step 5: Authorize Cross-Domain Reporting#

The rua address lives on a different domain (valkyrienexus.com) than most of the reporting domains, and RFC 7489 requires the receiving domain to opt in. Without the authorization record, providers silently drop the reports and the domain looks like it generates no DMARC traffic.

For each reporting domain, add a one-time TXT record on the valkyrienexus.com zone:

• Name: <reporting-domain>._report._dmarc (for example arnoldsappliancerepair.com._report._dmarc)
• Content: v=DMARC1

Exception: stonefyr.com reports to its own dmarc@stonefyr.com, so it needs no authorization record.

Verify:

dig +short TXT arnoldsappliancerepair.com._report._dmarc.valkyrienexus.com

Expected: "v=DMARC1".

Step 6: Run the Full DNS Verification#

Paste-safe block, run per domain:

DOMAIN=stonefyr.com
dig +short TXT "$DOMAIN" | grep -i 'v=spf1'
dig +short TXT "_dmarc.$DOMAIN"
dig +short TXT google._domainkey."$DOMAIN" | head -c40

Expected: one v=spf1 line (or none, for Resend-only and the correct hard-deny line for brand domains), a v=DMARC1 line with a rua=, and the start of a DKIM key (swap the selector to resend._domainkey for Resend domains, skip it for non-sending domains).

Step 7: Send the Outlook/Hotmail Test#

DNS looking right is not the finish line. Send a fresh message from the domain to an Outlook or Hotmail address, open the message source, and read the authentication results.

Expected, all three:

spf=pass
dkim=pass
dmarc=pass

Verify: The message landed in the inbox, not junk, and all three results read pass. Any fail or none means a record from Steps 2 through 4 is wrong for this domain's sender profile, go back and re-check against the table in Step 1.

Step 8: Climb the Policy Ladder#

DMARC enforcement is staged, never jumped:

1. p=none - monitor only, collect rua reports
2. p=quarantine - failing mail goes to spam
3. p=reject - failing mail is refused

Move up a rung only once the rua reports arriving at dmarc@valkyrienexus.com confirm nothing legitimate fails. Current fleet state: most domains at p=none, valkyrienexus.com at p=quarantine, valkyrienexus.dev locked at p=reject (non-sending, nothing legitimate can fail).

Verify: After each policy change, re-run the Step 6 dig and re-send the Step 7 test message.

Rollback#

1. Legitimate mail starts failing or bouncing after a policy bump - edit the _dmarc TXT back down a rung (p=reject to p=quarantine, or p=quarantine to p=none). This takes effect on DNS TTL, then diagnose via the rua reports.
2. SPF edit broke delivery - restore the previous SPF string. Cloudflare keeps the record in place, so re-edit rather than delete-and-recreate.
3. A second SPF or DMARC record was accidentally added - delete the duplicate immediately, the duplicate state is itself a failure mode.
4. Reports stopped arriving - check that dmarc@valkyrienexus.com still exists and is monitored, then check the _report._dmarc authorization records on the valkyrienexus.com zone for each reporting domain.

Maintenance Notes#

• The whole fleet was audited and brought to parity on 2026-06-06. Re-audit when adding a domain or changing a domain's sender.
• dmarc@valkyrienexus.com must stay a real, monitored mailbox or group. If it is ever deprovisioned, every domain's reports bounce and the ladder stalls.
• When a domain changes profile (a brand-only domain starts sending, or a site moves from Resend to Google Workspace), redo this runbook from Step 1. The records are profile-specific.
• Recurring review: read the rua reports before each planned policy bump, that is the only evidence that a bump is safe.
• New client sites run this runbook right after zone hardening as part of the launch checklist.