DMARC Deployment: Managing the Human Side of Email Security

DeploymentEmail TechnologySecurity Insights

DMARC Deployment Challenges Aren’t Always Technical

DMARC’s fundamentals are straightforward enough to get a solid understanding after a day’s study. You can learn enough to deploy it pretty quickly. 

• SPF publishes which servers can send for your domain. 
• DKIM signs messages with a key that you publish in DNS. 
• DMARC ties both to the domain your recipients actually see and tells receivers what to do when neither lines up. 

The parts that used to be painful are solved. DMARC vendors like dmarcian handle the aggregate report XML, match sending data like IP addresses to known senders, and show you which sources pass and which ones fail, all in a view humans can read. You don’t need to build any of that. 

The reports are also thorough. Every receiver that supports DMARC reporting tells you what it saw, so you get a list of everything sending as your domain: the mail platform, the ticketing system, the payroll provider, the survey tool someone signed up for in 2019, the campaign platform marketing bought last year. You don’t have to guess at your inventory. The data hands it to you. 

The technical work is knowable and measurable, the tooling exists, and most of the discovery problem is solved. The reports tell you which systems are sending. But they say nothing about who is responsible for those systems—that discovery phase is what sets your project timeline. 

Your email ecosystem has two halves

Sort your sending sources into two piles: 

IT owned: The mail platform, the email security gateway, monitoring and alerting systems, the service desk software, the enterprise resource planning (ERP) system, and anything else that comes from the IT budget. IT has admin access and can make changes directly. 

Business owned: Marketing automation, the customer relationship management (CRM) system, HR and payroll, applicant tracking, expense tools, event registration, survey platform, and billing. These were bought with a department’s budget, registered by department staff, and administered by a department’s people. IT often doesn’t have a login or even know the tool existed until it appeared in the DMARC reports. 

The business owned pile is usually bigger than anyone expects, and it’s where deployment goes to die. 

Getting a source compliant is rarely just an SPF change

A common assumption is that you add the vendor’s include to your SPF record and you’re done. That source is now DMARC compliant. That’s true for a small number of sources; for most third parties, it does nothing at all. 

DMARC requires alignment. The domain in the From header that your recipient sees in their inbox has to match the domain that passed SPF or DKIM. Most vendors send with their own return-path domain, so SPF authenticates their domain, not yours. Your SPF record is never even checked. You can add the include, the vendor’s documentation may even tell you to add the include (they’d be wrong), and the DMARC result stays exactly where it was: failing. 

Alignment comes from a change inside the vendor application. That happens one of two ways: 

Self serve: The provider has a sending domain or authentication page. You add your domain, it gives you DKIM keys or CNAME records to publish, you publish them, then come back and click verify. This work can be completed in minutes for someone with admin rights on that platform. 

By request: The provider doesn’t expose the setting. You open a support ticket and ask them to enable custom DKIM signing with your domain. They give you the DKIM or CNAME records to add, but not before the support request has been processed. Most times this option is free, sometimes it needs a plan upgrade, and sometimes it takes three weeks and two rounds of clarification and a meeting to get what you need. 

Either way, look at what both paths need: an account on the vendor’s platform with admin rights. In most cases, even filing a ticket means being a named contact on the account, and a login will authenticate you as well as your support entitlement.

IT can publish DNS records all day. Without access to the business systems, that’s where IT’s power ends. 

The search for the stakeholder

This is where the project is largely detective work. 

• Who owns this source? 
• Who has the admin login? 
• Who is the named contact with the vendor? 
• Who signs off on a paid add-on if that’s needed? 

You find that person eventually and that search involves its own set of challenges worth its own written guide.

High agency, low stakes

High agency. They own the system. They own the access. They have the vendor relationship, and they have the authority to approve or make a change. Nothing will happen to the source without them. 

Low stakes. They have never heard of DMARC. It isn’t their responsibility or goal; it isn’t in their job description. From where they sit, IT is asking them to log in to a tool they use for newsletters and change a setting. And they’re confused—IT expects them to fix a future problem on a hidden deadline. They didn’t cause the issue; to them, it causes no harm, and they had no say in the setting.

All are true at once, and that combination is what throws the timeline out the window. To the stakeholder, the request feels weightless. It goes to the bottom of a list that’s already full of work that their performance hinges upon. Two weeks later, you follow up, only to have to follow up two weeks after that. 

Rinse and repeat for the 10 to 20 business-owned sources found in your DMARC reports, often with each having a different owner and their own schedule. That’s the real bottleneck. These folks are not obstructive and they are not incompetent; they are simply rationally ignoring you because they don’t understand why they shouldn’t. 

DMARC project sponsorship

The only thing that reliably moves the needle is a mandate from someone with enough seniority to cover both IT and the business unit, or a true lateral collaboration between leadership. We previously touched on this in our previous piece about the complexity of higher education DMARC deployment. When the request arrives as part of the person’s job with a date their manager knows about, it stops being weightless and gains momentum. 

Sponsorship must be tangible, however, and here are a few things that can be done to ensure it:

• Build the owner list as early as possible. For every sending source, attach a name to it. 
• Get the mandate in writing from the sponsor and use it to build your communication plan when reaching out to owners. Make it visible to their managers. 
• If possible, give the exact steps for their specific vendor configuration requirements. If you aren’t sure what they are, leverage our source database or consider our support services. That’s what we do day in and day out. 
• Escalate on a schedule through the sponsor, before things go quiet for months. 

It’s also important to note what won’t rescue this process. AI won’t. It can draft your outreach and even read your reports to a point, but it can’t log into a marketing platform where it has no credentials or make a busy person care. Automation tools won’t either because most of these vendors expose no API for the setting you need changed, and the ones that do still require an account you likely don’t have. 

This is project management with stakeholder identification, a sponsor with real authority, clear asks, tracked commitments, and scheduled escalation. It’s not necessarily glamorous work, but it’s the part that decides whether you reach enforcement this quarter or next year. 

Plan the project around the people. The DNS records are never going to be the hard part. 

---

Want to continue the conversation? Head over to the dmarcian Forum.