Renew Your SPF/DKIM/DMARC Once a Year — A Calendar Reminder

"Set and forget" is not a safe strategy for email authentication. SPF records get stale as vendors come and go. DKIM keys age and eventually need rotation. DMARC policies written in 2023 are too permissive for 2027. Every year that passes without a review is a year your records drift further from the state your team actually believes them to be in. The calendar reminder costs nothing. The outage it prevents can cost six figures.

The calendar event

Create a single recurring annual calendar event: "Email auth renewal — SPF/DKIM/DMARC". Two hours blocked. Invite: the marketer who owns email + the engineer who controls DNS. Same month every year.

When to schedule it

Pick a low-volume month. For B2B: January, July. For e-commerce: February, August. For media and content: July. Anything but November–December. Make it the same month every year forever so institutional memory doesn't decay.

SPF review (30 minutes)

SPF (Sender Policy Framework) tells receivers which servers are allowed to send mail as your domain. It's a TXT record that looks roughly like this:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com -all

The annual review covers four things:

Every include is still in use. Pull the current SPF record. For each include:, confirm you still use that vendor. Remove any you don't.
DNS lookup count is under 10. SPF has a hard limit of 10 DNS lookups. Exceeding it breaks SPF silently. Use an SPF flattener or consolidation service if you're close. Most placement tests report this count.
Terminator is -all or ~all. Not ?all (too permissive), not +all (open to anyone). Hardfail (-all) is correct unless you have a specific reason not to.
Subdomains have SPF too. yourco.com has an SPF record but mail.yourco.com might not. If subdomains send mail, they need their own SPF.

DKIM review (30 minutes)

DKIM (DomainKeys Identified Mail) cryptographically signs your outgoing mail. Unlike SPF, DKIM lives in multiple TXT records named after "selectors" (e.g. selector1._domainkey.yourco.com).

Every active selector is current. Each ESP gives you one or two selectors. If you migrated ESPs or added a vendor, old selectors may still be in DNS. List them. Remove inactive ones.
Key length is at least 1024, ideally 2048. 1024 was standard in 2010. In 2027, 2048 is the floor. Below 1024 is a placement risk.
Rotate at least one key. Best practice is annual rotation. If you've never rotated, this is the year. Your ESP has documented the process.
DKIM signs all outbound, including transactional. Send a test from every sending system you use (marketing ESP, transactional ESP, CRM, support tool) and check DKIM passes on each.

Test DKIM across all senders

Run a placement test from every single sending system. DKIM misses on secondary senders (billing, support, sales) are the most common annual finding.

DMARC review (30 minutes)

DMARC ties SPF and DKIM to a policy. It's the record that tells receivers what to do with mail that fails auth.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourco.com; pct=100; adkim=s; aspf=s

Policy is not p=none. p=none is monitoring-only and protects nothing. If you've had it at p=none for more than 6 months, this is the year to move to p=quarantine.
Alignment is s (strict), not r (relaxed), if you can. Strict alignment is the stronger posture. Some legacy setups require relaxed; most don't.
Reports are going somewhere. rua= should point to a mailbox or a DMARC parsing service. If it points to an old employee's address, fix that.
Review recent reports. Open the DMARC reports from the last 30 days. Any unexpected senders? Any large volume failing alignment? Those are investigation items.
BIMI alignment (optional). If you run BIMI, this is the year to confirm VMC, DMARC alignment, and image still valid.

The output: three lines in a doc

At the end of the two hours, three lines go into the quarterly review doc:

SPF reviewed YYYY-MM-DD, X includes, Y DNS lookups, no changes / Z removed
DKIM reviewed YYYY-MM-DD, N active selectors, key rotated (yes/no)
DMARC reviewed YYYY-MM-DD, policy p=quarantine, alignment strict, reports reviewed

Three lines. Written once a year. They become a paper trail that proves (to compliance auditors, new hires, your future self) that the auth stack is actively maintained.

Common findings in the annual review

A vendor you stopped using 18 months ago is still in SPF
DKIM selector for an old ESP still in DNS, old ESP still sending test mail from it
DMARC at p=none since setup, never upgraded
DMARC reports going to dmarc@yourco.com which has zero routing set up
Subdomain mail.yourco.com sends marketing but has no SPF
DKIM key length 1024 on one selector, 2048 on another

None of these are catastrophic individually. Add three or four together and placement degrades in ways nobody can figure out without the annual review.

FAQ

Is once a year really enough?

For most programs, yes, provided you also do a quarterly health review. The annual is for records hygiene; the quarterly is for placement drift. They cover different things.

Does changing DNS break things?

Only if you change the wrong thing. The review is mostly about confirming current state, not changing it. Actual changes (rotating DKIM, tightening DMARC) should be planned with 30-day windows and monitored.

What if I don't own DNS?

Find out who does. If it's a legacy agency, an old CTO, or a dormant IT provider, reclaiming DNS ownership is a Q1 priority in its own right.

Do I need to rotate DKIM keys every year?

Best practice yes, but it's not absolute. If you haven't rotated in 3+ years, do it this year. After that, every 1–2 years is fine as long as key length is 2048.

Renew SPF, DKIM, DMARC once a year