Chat Approvals Are Not Change Control for Email DNS

The Incident That Should Not Have Been an Incident

A project manager got a webinar vendor approved via Slack chat 30 minutes before a campaign launch. The commercial side was handled. Then someone asked for the vendor to be added to the company's SPF record and for DKIM to be configured. The pushback was exactly what you would expect: "it is just TXT records."

IT made the change. A few days later, aggregate reports showed the vendor had been sending unauthenticated mail for two days. DMARC reports flagged alignment failures on every message. The company domain had sent roughly 4,000 messages that looked like they came from the company but had never passed a single authentication check. Some of those messages had landed in spam. The vendor had not actually configured DKIM signing before the campaign started. The IT team had added them to SPF based on the vendor's word.

This is the scenario DMARCFlow is designed to catch. DMARCFlow parses your aggregate reports and surfaces alignment failures by source the moment they appear. If the webinar vendor had been monitored this way after going live, the unauthenticated sending would have surfaced within hours, not days. Instead, the problem was discovered in a post-mortem after the domain reputation had already taken a hit.

This is what "just TXT records" actually costs when the records in question are SPF, DKIM, and DMARC.

Why Email Authentication DNS Records Are Not Just TXT Records

Most DNS records control where traffic goes. SPF, DKIM, and DMARC control who can send mail on your behalf and how receivers treat it.

SPF authorizes which mail servers are allowed to send for your domain. When you add a vendor to your SPF record, you are telling every receiver in the world: "mail from this server is authorized by this domain." If that vendor's servers are on a blocklist, or if they get compromised, your SPF record is now part of the problem.

DKIM attaches a cryptographic signature to every outgoing message. The receiving server verifies the signature against a public key you publish in DNS. If the signature passes, the message was not altered in transit. If it fails, something is wrong.

DMARC sits above both. It requires that whichever authentication method passes, the domain in the message From header must match the domain that passed SPF or DKIM. Without DMARC alignment, a sender could pass SPF by sending from their own server but claim to be from your domain. DMARC catches that.

A change to any one of these records changes who can send authenticated mail on behalf of your domain. These are not routine DNS maintenance tasks.

What Can Actually Go Wrong

SPF include pointing to a blocklisted IP. Vendors sometimes send from shared infrastructure. If that IP appears on a major blocklist, every receiver that checks that list starts rejecting your mail. You will not know this happened until your sending volumes drop or you get a complaint.

Vendor claims DKIM is configured but alignment is wrong. The vendor can show you DKIM passing in their test environment. But if they are signing with their own subdomain rather than your domain in the From header, DMARC alignment fails on every message. The vendor sees DKIM passing. Your aggregate reports see DMARC failures. These two realities coexist because nobody is looking at the reports.

DMARC policy set to reject before all sending paths are validated. If you move from p=none to p=quarantine or p=reject before confirming every legitimate source is passing alignment, you will silently drop mail from business-critical senders. This happens more often than it should.

SPF record grows without limits as vendors accumulate. Each new vendor adds an include. After a few years, SPF records can contain dozens of includes, any one of which can introduce risk. This is called SPF recursion depth, and some receivers have hard limits on how many SPF lookups they will perform.

Old vendor stays in the SPF include after they stop sending. When a vendor relationship ends, nobody removes them from SPF. The include stays in the record indefinitely, representing a potential attack surface.

The Minimum Change Control Checklist

This is not a three-week CAB process. It is a half-page checklist that fits between a ticket and a rollback plan.

Before any SPF, DKIM, or DMARC change:

A ticket exists with an owner who understands what they are approving, not just someone who can click the button.
A DNS diff shows exactly what is being added or removed. "Adding Mailchimp" is not a diff. The actual record before and after is a diff.
A rollback plan exists with the previous record state documented and tested.
Proof the vendor can sign DKIM aligned to your domain. "DKIM is configured" is not proof. The actual authentication headers on a live test message are proof.
The exact sending domain and From addresses the vendor will use are documented.
A test send goes to a known-good inbox with full headers inspected. Authentication-Results headers must show DKIM pass and alignment pass.
Confirmation of who holds the domain credentials. If it is a consultant who is not answering tickets, that is a risk worth naming in the ticket.

How to Run the DKIM Alignment Test

This is the step most often skipped and the one that catches the most problems.

Ask the vendor for their DKIM selector and public key. Have them send a test message to an address you control. Open the full headers. Look for the Authentication-Results header.

A passing DKIM alignment looks like this:

Authentication-Results: mx.example.com; dkim=pass header.d=yourdomain.com header.s=selector; spf=pass mail.from=yourdomain.com; dmarc=pass header.from=yourdomain.com

If you see dkim=fail or dkim=pass header.d=vendor-their-domain.com (a different domain from your From header), the vendor is not sending aligned DKIM. They may be sending DKIM, but it will not help your DMARC alignment. In that situation, do not add them to your SPF record until the DKIM alignment is fixed. Adding them to SPF masks the problem in aggregate reports because SPF will pass even though DMARC alignment fails.

How Aggregate Reports Catch What the Checklist Misses

The checklist covers pre-flight checks. DMARCFlow monitors what happens after the change goes live.

Aggregate reports tell you which sources are sending mail for your domain, which authentication methods they are using, and whether alignment is passing or failing. When a vendor changes their sending infrastructure without telling you, aggregate reports surface it as a new source with alignment failures. When a vendor stops DKIM signing and starts sending unauthenticated mail, aggregate reports show the DKIM failures.

This is the difference between finding out about a problem from a spam complaint and finding out from your own monitoring. DMARCFlow parses the XML aggregate reports and turns them into a readable dashboard showing pass rates by source, alignment failures by domain, and SPF include performance. If the webinar vendor had been monitored this way after going live, the unauthenticated sending would have appeared within hours, not days.

What to Do When the Campaign Is Time-Sensitive

If the blast is genuinely urgent and the vendor passes the alignment test:

Use a short-TTL SPF include for the campaign vendor so you can remove it quickly afterward.
Set a calendar reminder to check aggregate reports 24 hours after the campaign ends.
Remove the vendor from SPF if they cannot provide aligned DKIM before the campaign. Mail that fails DMARC will likely land in spam anyway.

If the vendor does not pass the alignment test, do not let it ship. Mail that appears to come from your domain but fails DMARC damages your domain reputation. A campaign that lands in spam is not a successful campaign.

FAQ

What is the minimum process for adding SPF or DKIM records?

A ticket with an owner, a DNS diff, a rollback plan, a DKIM alignment test on a live message, and a check of aggregate reports after go-live. That is the minimum.

Can I add a vendor to my SPF record without a formal change process?

You can, but the checklist above is not optional. The risk is not the DNS change itself. The risk is the vendor sending unauthenticated mail that damages your domain reputation while you are not looking.

How do I validate a vendor can send authenticated email?

Run the DKIM alignment test described above. If the vendor cannot produce aligned DKIM before your campaign, do not add them to SPF. SPF without aligned DKIM means your DMARC alignment will fail on every message.

How long does it take for SPF, DKIM, or DMARC changes to take effect?

SPF and DMARC changes take effect within minutes to a few hours. DKIM changes depend on DNS propagation and when the vendor starts signing. Some selectors take up to 48 hours to propagate globally. Monitor aggregate reports for at least a week after any major change.

What does a DMARC aggregate report show after a DNS change?

It shows which sources sent mail for your domain, whether they passed SPF and DKIM, and whether alignment passed. If a new source appears with alignment failures, that is your signal to investigate before it becomes a domain reputation problem.