How to Get Your Vendors to Fix Email Authentication
A practical guide to coordinating with ESPs, CRMs, and other services to fix DMARC, SPF, and DKIM issues.
You’ve set up DMARC. You’re looking at your reports. And you’ve found the problem: one of your vendors is sending email as your domain without proper authentication.
Now comes the hard part. You need to get them to fix it.
This guide covers the practical side of vendor coordination. How to identify what’s wrong, how to communicate it clearly, and how to actually get results instead of endless support ticket loops.
Why vendor coordination is the real challenge
Reaching DMARC enforcement requires every legitimate sender to authenticate correctly. Your email provider, your marketing platform, your CRM, your support desk, your transactional email service. All of them.
Most of these services can authenticate properly. The technology exists. But it’s not always configured by default, and getting it configured often means working with vendor support teams who may not understand DMARC.
This is where most DMARC projects stall. Not because the technology is hard, but because the coordination is tedious. You open a ticket. You wait. You get a response asking you to “check your DNS.” You explain that DNS is fine and the problem is on their end. You wait again.
The companies that reach enforcement are the ones who figure out how to make this process efficient. Start by understanding your DMARC reports to identify exactly which vendors need attention.
Step 1: Identify what’s actually failing
Before you contact any vendor, you need to understand exactly what’s wrong. Vague tickets get vague responses.
Check your DMARC reports for the specific sending source. Look for:
The source IP or IP range sending the failing email. This tells you which service is the problem.
Which authentication is failing. Is it SPF, DKIM, or both? This determines what needs to be fixed.
Whether it’s an authentication failure or an alignment failure. SPF might pass for the vendor’s domain but fail alignment because it doesn’t match your From address. This is different from SPF failing entirely.
The volume of affected messages. Is this 10 emails a day or 10,000? Volume helps prioritize and also tells the vendor how important this is.
If you’re using Verkh, this information is already parsed and displayed clearly. If you’re reading raw DMARC reports, you’ll need to dig through the XML to find these details.
Step 2: Determine what fix is needed
Different failures require different fixes:
SPF alignment failure
The vendor’s servers are sending email, but they’re using their own Return-Path domain instead of yours. SPF passes for their domain but doesn’t align with your From address.
The fix: Configure a custom Return-Path (also called envelope sender or bounce address) with the vendor. Not all vendors support this. If they don’t, you’ll need to rely on DKIM for alignment instead.
DKIM alignment failure
The vendor is signing emails, but with their own domain in the d= tag instead of yours. DKIM passes but doesn’t align.
The fix: Enable custom DKIM signing. Most major ESPs support this. You’ll typically need to add 2-3 CNAME records to your DNS, and the vendor will start signing with your domain.
DKIM not present
The vendor isn’t signing emails with DKIM at all.
The fix: Enable DKIM in the vendor’s settings and add the required DNS records. This is usually a configuration option in the vendor’s dashboard.
SPF failure (not just alignment)
The vendor’s sending IPs aren’t in your SPF record at all.
The fix: Add the vendor’s SPF include statement to your SPF record. For example: include:sendgrid.net or include:spf.mailchimp.com. Check the vendor’s documentation for the correct include. Use our SPF checker to verify your record after making changes.
Step 3: Check if you can fix it yourself
Many authentication issues can be resolved without contacting support at all. Before opening a ticket:
Check the vendor’s dashboard for domain authentication settings. Most ESPs have a section called “Domain Authentication,” “Sender Authentication,” or “Custom Domain” where you can configure SPF and DKIM.
Check the vendor’s documentation. Search for “DKIM setup” or “domain authentication” in their help center. Many vendors have step-by-step guides.
Check your DNS records. If you previously set up authentication but it’s not working, verify the records are still in place and match what the vendor expects.
If you can fix it yourself, do it. It’s faster than waiting for support.
Step 4: Write an effective support request
When you do need to contact support, clarity is everything. Here’s what to include:
Subject line
Be specific. Not “Email authentication issue” but “DKIM alignment failing for emails sent via [Service Name] for domain example.com”
Body structure
1. State the problem clearly.
Emails sent through [Service Name] for our domain example.com are failing DMARC authentication due to DKIM alignment issues. The DKIM signature uses d=vendor.com instead of d=example.com.
2. Provide evidence.
Our DMARC reports show the following:
- Sending IP: 198.51.100.x
- DKIM result: pass (but not aligned)
- DKIM domain: vendor.com
- From domain: example.com
- Volume: approximately 2,000 emails/day
3. State what you need.
We need to configure custom DKIM signing so emails are signed with d=example.com. Please provide the CNAME records we need to add, or direct us to the configuration option in the dashboard.
4. Mention business impact if relevant.
This is blocking our ability to move to DMARC enforcement, which is required for PCI DSS compliance.
What not to do
Don’t send a wall of text. Don’t paste raw XML. Don’t ask them to “fix DMARC” without explaining what specifically is wrong. Don’t be vague about which domain or which sending service you’re asking about.
Step 5: Escalate effectively
If the first response doesn’t help, escalate with additional context:
Reference ticket numbers. “Following up on ticket #12345 opened on January 5th.”
Clarify misunderstandings. If they told you to “check your DNS” when DNS is fine, explain: “We’ve verified our DNS records are correct. The issue is that your servers are signing with d=vendor.com instead of d=example.com. This is a configuration on your end, not ours.”
Ask for a specialist. “Can this be escalated to someone familiar with DKIM and DMARC configuration?”
Reference their own documentation. If they have a help article about custom DKIM and their support team seems unaware, link to it.
Common vendors and what to ask for
Here’s what you typically need from the most common email sending services:
Google Workspace
DKIM signing is available but must be enabled. Go to Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Generate a DKIM key and add the TXT record to your DNS.
Microsoft 365
DKIM is enabled by default for custom domains, but you need to publish the DKIM records. Go to Microsoft 365 Defender → Email & collaboration → Policies → DKIM. Enable and add the CNAME records provided.
SendGrid
Enable domain authentication in Settings → Sender Authentication. You’ll add CNAME records for DKIM and optionally configure a custom Return-Path for SPF alignment.
Mailchimp
Enable custom domain authentication in Settings → Domains. Mailchimp provides CNAME records for DKIM. Note that Mailchimp typically handles SPF through DKIM alignment rather than custom Return-Path.
HubSpot
Connect your email sending domain in Settings → Domains & URLs → Email Sending Domains. HubSpot provides CNAME records for DKIM and can configure a custom Return-Path.
Salesforce
Configure email authentication in Setup → Email → DKIM Keys. Create a new key and add the TXT record to your DNS. Salesforce requires some specific configuration depending on how you’re sending email.
Amazon SES
Set up custom MAIL FROM domain in SES Console → Verified Identities → your domain → Custom MAIL FROM domain. For DKIM, enable Easy DKIM and add the CNAME records provided.
For other vendors, search their documentation for “DKIM,” “domain authentication,” or “email authentication.”
Tracking vendor progress
When you’re coordinating with multiple vendors, keep track of where each one stands:
| Vendor | Issue | Ticket # | Status | Last Contact | Next Step |
|---|---|---|---|---|---|
| SendGrid | DKIM alignment | 12345 | Waiting on DNS | Jan 5 | Add CNAMEs |
| HubSpot | No DKIM | 67890 | Escalated | Jan 7 | Waiting for specialist |
| Old CRM | SPF missing | N/A | Researching | Jan 3 | Find include statement |
Update this after every interaction. When someone asks about email authentication progress, you have a clear answer.
When vendors can’t or won’t help
Sometimes you hit a wall. The vendor doesn’t support custom DKIM. Support doesn’t understand what you’re asking. The feature requires an enterprise plan you don’t have.
Options:
Use a subdomain. If the vendor can’t authenticate for your main domain, consider using a subdomain like mail.example.com or notifications.example.com. You can set up separate authentication for the subdomain.
Accept partial authentication. If DKIM alignment isn’t possible, ensure SPF is properly configured and aligned. You only need one mechanism to align for DMARC to pass.
Replace the vendor. If email authentication is critical and the vendor can’t support it, that’s a reason to switch. Many companies have migrated away from services that couldn’t meet their authentication requirements.
Exclude and monitor. In some cases, you may need to proceed to enforcement while still monitoring a problematic sender. This is a last resort and means accepting that some legitimate email from that source may be affected.
Using shareable reports
One of the most effective ways to move vendor conversations forward is to give support teams something they can actually use.
Instead of explaining DMARC in a support ticket, send them a report that shows:
- Which emails are failing
- What specifically is wrong
- What they need to do to fix it
- Links to their own documentation
Verkh generates shareable Apex dashboards for exactly this purpose. You create a link, send it to the vendor, and they can see the authentication failures in a format designed for people who may not know DMARC terminology.
When a support rep can see “DKIM signature uses vendor.com, needs to use example.com” with visual evidence, the conversation changes. They stop asking you to check your DNS and start looking at their own configuration.
The coordination checklist
Before reaching out to any vendor:
- Identified the specific sending source (IP/service)
- Determined which authentication is failing (SPF, DKIM, or alignment)
- Checked if the fix can be done through vendor dashboard
- Reviewed vendor documentation for setup guides
- Prepared specific details (domain, IPs, volumes, error messages)
When writing the support request:
- Clear subject line with domain and issue type
- Specific problem statement (not “DMARC isn’t working”)
- Evidence from DMARC reports
- Clear ask (what records you need, what configuration you need)
- Business context if helpful for prioritization
After initial contact:
- Logged ticket number and date
- Set reminder to follow up if no response in 48-72 hours
- Prepared escalation path if first response doesn’t resolve
Moving forward
Vendor coordination is the unglamorous work that separates companies who reach DMARC enforcement from those who stay stuck at p=none forever. It’s not technically complex. It’s just persistent.
The good news: each vendor only needs to be fixed once. Once SendGrid is authenticating correctly, it stays that way. The work you do now compounds. Every vendor you fix is one less blocker between you and enforcement.
Make vendor coordination easier
Verkh identifies authentication failures, shows exactly what’s wrong, and generates shareable dashboards you can send directly to vendor support. Stop explaining DMARC in tickets. Start sending evidence.
Ready to implement this?
Verkh helps you monitor DMARC, identify issues, and reach enforcement. Start free.
Start Free