Email Deliverability for Sales Reps

Somewhere right now, a sales rep on your team just sent a perfectly written email to a qualified prospect. The subject line was sharp. The pitch was tight. The CTA was clear. And it landed in a spam folder that prospect will never check.

This happens more than most B2B teams realize. We see it constantly when we audit client HubSpot portals — beautifully crafted sequences, smart segmentation, solid copy — all undermined by a broken email authentication setup that nobody on the team has looked at since the domain was first set up five years ago. The result is a deliverability tax that quietly compounds: lower reply rates, fewer meetings booked, weaker pipeline, and a sales team that blames the copy when the real problem is DNS.

The fix isn't complicated. It is, however, technical and unforgiving — a single typo in a DNS record can either break your mail flow or leave you exposed to spoofing. This guide walks through the entire setup for both Microsoft 365 and Google Workspace, covers the third-party sender problem that catches most teams off guard, and gives you the diagnostic and monitoring workflow we use when auditing client environments.

Read it once to fix your domain. Bookmark it for the next time a deal goes silent and you're trying to figure out whether your email actually got delivered.

The hidden tax on your revenue: what broken email authentication actually costs you

Email deliverability is the unsexiest topic in B2B revenue operations, and that's exactly why it stays broken. It doesn't show up in any standard sales report. It doesn't trigger an alert. Nobody on the marketing team gets a Slack notification that says "47% of your campaign just got filtered to spam." The damage happens silently, in inboxes you can't see.

Here's what broken authentication actually costs a typical B2B team. Imagine a 10-person sales team sending 50 cold outreach emails per day, per rep. That's 500 emails daily, or roughly 130,000 emails per year. If your authentication is broken badly enough that 30% of those emails land in spam — which is a realistic number for a domain with failing SPF, DKIM, and DMARC — you've effectively erased 39,000 outreach attempts from your pipeline. At a 2% meeting-booking rate, that's 780 meetings you didn't get. At your average deal size and close rate, do the math on what that represents in lost revenue.

And cold outbound is just the most obvious case. Broken authentication also damages your transactional mail. Customer notifications, password resets, invoice reminders, support ticket replies — when any of these land in spam, your customers either think you're ghosting them or open a support ticket complaining they "never got the email." Your team burns hours per week resending mail that should have been delivered the first time.

There's also a reputation cost that gets worse over time. Mail providers like Gmail, Outlook, and Yahoo track every domain's authentication history. The longer your domain sends mail that fails authentication, the more aggressively those providers filter you — even after you fix the underlying problem. Recovery from a damaged sender reputation can take 60 to 90 days of clean sending, which means the cost of letting this stay broken compounds month over month.

And as of February 2024, Google and Yahoo formalized what had been informal best practice: any sender pushing more than 5,000 messages per day to Gmail or Yahoo users is now required to have SPF, DKIM, and DMARC properly configured. Senders who don't comply see immediate deliverability degradation. If your domain hasn't been audited since this rule change, there's a meaningful chance you're already paying the price and don't know it.

The good news: this is one of the highest-ROI fixes in revenue operations. The work to get authentication right is typically a one-time effort that takes a few hours, plus ongoing monitoring that takes maybe 15 minutes per month. The downstream impact — recovered deliverability, better sender reputation, fewer support tickets about missing emails, stronger reply rates on outbound — pays back the investment within weeks.

The three records that make or break your deliverability: SPF, DKIM, and DMARC explained

Before fixing anything, you need a working mental model of what each record does. The official RFC definitions are dense, but the practical version is straightforward.

SPF (Sender Policy Framework) is a DNS record that lists which mail servers are allowed to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from you@yourdomain.com, it checks the SPF record at yourdomain.com to see if the sending server's IP address is on the approved list. If yes, SPF passes. If no, SPF fails. Think of SPF as a guest list for your domain — only the servers you've explicitly named are allowed to send mail using your address.

SPF is published as a single TXT record in DNS that looks something like this:

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

The includes are pointers to other organizations' SPF records (in this case, Microsoft, Google, and Mailchimp), and the -all at the end means "reject everything not on this list." SPF has a critical limit: a single record can only chain together 10 DNS lookups total. If you're sending through many third-party services, you can easily blow past this limit and SPF will silently start failing.

DKIM (DomainKeys Identified Mail) is a cryptographic signature applied to outgoing messages. When your mail server sends an email, it adds a digital signature to the headers using a private key that only you control. The receiving server fetches your public key from DNS, uses it to verify the signature, and confirms that the message was actually sent by you and wasn't modified in transit. If the signature verifies, DKIM passes. If the message was altered after signing — for example, by a downstream service that injects content — the signature breaks and DKIM fails.

DKIM is the most technically robust of the three, but also the most fragile to misconfiguration. It involves both your mail platform (which signs the messages) and your DNS (which publishes the public key at a specific selector name like selector1._domainkey.yourdomain.com). Both sides have to be configured correctly or DKIM will silently fail every message.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that ties SPF and DKIM together and tells receiving servers what to do when one or both fail. DMARC requires that at least one of SPF or DKIM pass with alignment — meaning the domain that authenticated must match the domain in the visible "From" address. DMARC also generates aggregate reports that get sent back to you, so you can see exactly which messages are passing and failing from every sending source.

A DMARC record looks like this:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1

The p= tag is the policy: none (monitor only, don't block anything), quarantine (route failing mail to spam), or reject (refuse failing mail outright). The rua= address gets aggregate reports — XML files summarizing what passed and failed across all receivers — and the ruf= address gets forensic reports of individual failures.

The relationship between the three: SPF answers "is this server allowed to send for this domain?" DKIM answers "was this specific message genuinely sent by this domain and unaltered?" DMARC answers "what should you do if the answer to either of those is no, and how do I know it's happening?" All three need to work in combination — fixing one and ignoring the others leaves gaps that mail providers will treat as suspicious.

How to diagnose if your domain is failing authentication (in 5 minutes or less)

Before you change anything, find out what's actually broken. There are three diagnostic paths, ranging from "thirty seconds in a Gmail inbox" to "comprehensive third-party audit."

The Gmail "Show original" trick. This is the fastest diagnostic and requires nothing except a Gmail account you control. Send a test email from the domain you want to check to that Gmail address. Open the message in Gmail's web interface. Click the three-dot menu next to the reply button, then click "Show original." At the top of the resulting view, Gmail displays the authentication results in plain language:

SPF:    PASS  with IP 40.107.236.45
DKIM:   PASS  with domain yourdomain.com
DMARC:  PASS

You want all three lines to say PASS. If any one of them says FAIL or NEUTRAL, that's your problem. For DKIM specifically, also check that the "domain" listed is your domain — not a third-party service's domain. If DKIM passes but with domain sendgrid.net or exclaimer.net instead of yourdomain.com, your DMARC alignment is broken even though DKIM technically passed.

The mxtoolbox snapshot. If you want a more thorough check than a single test email, mxtoolbox.com offers a free "SuperTool" that queries your domain's SPF, DKIM, and DMARC records directly from DNS. Plug in your domain and select "MX Lookup," "SPF Record Lookup," and "DMARC Lookup." This tells you what's published in DNS regardless of whether you can send a test email. It won't catch problems that only show up at send time (like DKIM signing failures or alignment issues), but it's a fast way to confirm the foundational records are in place.

DMARC aggregate reports. This is the most thorough diagnostic, and also the most strategic. If you publish a DMARC record with a valid rua= address — even with p=none as the policy — every major mail provider will send you daily XML reports showing exactly which sources sent mail using your domain, which passed authentication, and which failed. These reports are unreadable raw, but tools like dmarcian, Postmark DMARC Digests, EasyDMARC, and Valimail Monitor parse them into clean dashboards. After two to four weeks of monitoring, you'll have a complete picture of every service sending mail as your domain, including some you forgot you had (and possibly some you never authorized).

The triage rule: if Gmail "Show original" shows all three passing for mail sent from your primary mail platform, your foundation is solid. If anything fails, fix that first. Once the foundation is solid, set up DMARC monitoring to catch the third-party services that almost always have hidden problems.

One thing to know before you dive in: changes to DNS-based authentication don't take effect instantly. SPF and DMARC are TXT records, which typically propagate in 15 minutes to a few hours but can take up to 24 hours depending on TTL settings. DKIM CNAMEs follow the same pattern. Build in a propagation window before you re-test, and don't assume your fix failed just because it's not visible 10 minutes after publishing the record.

Fixing SPF, DKIM, and DMARC in Microsoft 365

Microsoft 365 (formerly Office 365) is the most common business email platform we encounter when auditing client environments. The fix path is well-defined but involves both the Microsoft 365 admin consoles and your DNS host. Here's the full sequence.

Step 1: Verify SPF includes Microsoft. In your DNS provider (GoDaddy, Cloudflare, Route 53, whoever hosts your domain), find the existing SPF TXT record for your domain. It should already contain include:spf.protection.outlook.com. If it doesn't, M365 mail probably isn't flowing correctly in the first place. The complete record for a domain sending only through M365 looks like:

v=spf1 include:spf.protection.outlook.com -all

If you're sending through other services too, each one gets its own include. We'll cover the third-party sender problem in detail in a later section.

Step 2: Enable DKIM signing in Microsoft 365. Go to security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. You'll see a list of accepted domains. Click the domain you want to authenticate. Microsoft will display two CNAME records that need to be published in DNS:

Host:   selector1._domainkey.yourdomain.com
Points to: selector1-yourdomain-com._domainkey.<tenant>.onmicrosoft.com

Host:   selector2._domainkey.yourdomain.com
Points to: selector2-yourdomain-com._domainkey.<tenant>.onmicrosoft.com

The <tenant> value is your specific Microsoft 365 tenant name. Microsoft displays the exact values to use — copy them verbatim. Publish both CNAMEs in DNS, wait for them to propagate (usually under an hour), then return to the DKIM panel and click Enable. If the CNAMEs aren't resolving yet, Microsoft will reject the enable attempt with an error about the records not existing. Wait longer and try again.

Step 3: Publish a DMARC record. In DNS, create a new TXT record at the host _dmarc.yourdomain.com. For initial deployment, start with monitoring mode:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

This tells mail providers to report on authentication results without blocking anything. After two to four weeks of monitoring (covered in a later section), you'll graduate the policy to p=quarantine and eventually p=reject.

Step 4: Watch out for the third-party signature service trap. This is the single most common cause of M365 deliverability failure we see in audits. If your organization uses a third-party email signature service like Exclaimer, CodeTwo, Crossware, or Rocketseed, those services receive mail from M365, modify the body to inject the signature block, and re-send it. The body modification invalidates the DKIM signature M365 originally applied. Unless the signature service is configured to re-sign messages with your domain's DKIM key — and unless its sending IPs are added to your SPF record — every email you send will fail authentication.

The fix involves both the third-party service and DNS. In the signature service's admin portal, enable DKIM signing for your domain. The service will generate its own public key and provide a CNAME to publish in DNS. Once that resolves, activate signing in the service. Also add the service's SPF include to your existing record. After the fix, your outbound mail will carry two DKIM signatures (M365's original signature, which is now invalid, and the signature service's new signature, which is valid), and DMARC only requires one to pass with alignment.

Step 5: Verify in Microsoft's reporting. M365 has its own authentication reporting under admin.microsoft.com → Reports → Email & collaboration → Mailflow status summary. After the fix propagates over 24 to 48 hours, the authentication failure rate should drop to near zero. If it doesn't, your DMARC aggregate reports (from the rua address you published in step 3) will pinpoint exactly which sending sources are still failing.

Fixing SPF, DKIM, and DMARC in Google Workspace

The Google Workspace setup follows a parallel pattern, with admin consoles in different locations and slightly different DNS records.

Step 1: Configure SPF for Google Workspace. In DNS, your SPF record needs to include Google's mail servers. A domain sending only through Google Workspace uses:

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

Google's default recommendation uses ~all (soft fail) rather than -all (hard fail). For most B2B environments where you've properly accounted for every sending service, -all is more secure and what you'll want once DMARC is enforced. But during initial setup, ~all is the safer starting point.

Step 2: Generate and publish your DKIM key. Go to admin.google.com → Apps → Google Workspace → Gmail → Authenticate email. Select your domain from the dropdown. Click Generate new record. Google will generate a 2048-bit DKIM key and display the DNS TXT record you need to publish. It looks something like:

Host:   google._domainkey.yourdomain.com
Type:   TXT
Value:  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB...

The p= value will be a very long string of base64-encoded public key data. Copy it carefully — even a single missing character will break verification. Publish the TXT record in DNS, wait for propagation, then return to the Google Workspace admin console and click Start authentication. Google will verify the key resolves and activate signing.

Step 3: Publish your DMARC record. Same as the Microsoft 365 case — create a TXT record at _dmarc.yourdomain.com starting with monitoring mode:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

The DMARC standard is the same regardless of mail platform — it's a policy layer on top of SPF and DKIM, not a platform-specific configuration.

Step 4: Handle subdomains and the routing rules trap. Google Workspace has a quirk that catches teams off guard: if you use email routing rules (for example, forwarding to an external service before re-delivery), those routing steps can break DKIM alignment in ways similar to the Exclaimer scenario in M365. If you've got any "Hosts" entries under Apps → Gmail → Hosts or any rerouting under Apps → Gmail → Routing, audit those to make sure they're not modifying mail in transit.

Subdomains are a related trap. If you send transactional mail from a subdomain (like notifications.yourdomain.com) but your DMARC policy is only published at the parent (yourdomain.com), the subdomain inherits the policy by default — but if there's no DKIM key published at the subdomain level, mail from that subdomain will fail. The fix is either to publish DKIM at every subdomain you send from, or to add a permissive subdomain policy with sp=none in your DMARC record until you've authenticated the subdomains properly.

Step 5: Verify with the Postmaster Tools. Google offers a free service called Postmaster Tools at postmaster.google.com that provides domain-level metrics on spam rate, reputation, authentication pass rate, and feedback loop data. Add your domain, verify ownership with a TXT record, and monitor it weekly. Postmaster Tools is the closest thing to a deliverability dashboard Google publishes — if your authentication setup is healthy, you'll see authentication pass rates close to 100% and a "High" domain reputation score.

The third-party sender problem: HubSpot, Mailchimp, sales sequencers, and signature services

Even with Microsoft 365 or Google Workspace set up perfectly, the vast majority of authentication failures we see in B2B environments come from third-party services that send email on behalf of the domain. A typical revenue team might be sending through five to ten distinct sources without realizing it: their primary mail platform, a marketing automation tool, a transactional email API, a sales engagement platform, a webinar tool, a survey tool, an e-signature service, and an email signature management tool. Each one is a potential authentication failure point.

The principle: every service that sends email using your domain needs to be either added to your SPF record (so its sending IPs are authorized) or set up to DKIM-sign as your domain (so its messages have a verifiable signature). Ideally both. If a service isn't authenticated, mail it sends will either fail outright (under DMARC reject) or land in spam (under quarantine), even though everything else is configured correctly.

HubSpot. If you use HubSpot for marketing emails, sales sequences, or transactional notifications, you need to enable HubSpot's email sending domain feature. In HubSpot, go to Settings → Marketing → Email → Configuration → Email sending domain. Connect your domain, and HubSpot will provide DNS records for both SPF (a TXT record) and DKIM (a CNAME). Publish both. HubSpot's deliverability will improve immediately, and your DMARC alignment will work correctly because HubSpot will sign as your domain instead of as hubspot.com.

Mailchimp, Constant Contact, and other marketing platforms. Every major marketing automation platform supports domain authentication. The process is always the same: connect your domain in the platform, publish the SPF and DKIM records they provide, verify in the platform's admin UI. None of these are optional anymore — Google and Yahoo's bulk sender requirements specifically target marketing platforms, and unauthenticated mail from these tools gets filtered aggressively.

Sales engagement platforms like Salesloft, Outreach, and Apollo. These tools usually let you connect individual mailboxes directly via OAuth, which means the mail actually flows through your primary mail platform (M365 or Google) rather than the sequencer's own servers. When configured this way, your existing SPF and DKIM cover the outbound mail and no separate authentication is required. But some platforms also offer a "send via our infrastructure" mode for higher volume — if you've enabled that, you need to authenticate it separately following the platform's setup instructions.

Email signature services like Exclaimer, CodeTwo, Crossware, and Rocketseed. These are the silent killers we mentioned earlier. They sit downstream of your mail platform, modify the body to inject signatures, and forward the message to the recipient. The body modification breaks DKIM. Unless the signature service is configured to re-sign as your domain (most of them support this — check the admin portal's DKIM section), you'll fail authentication on every outbound message. Also add the service's SPF include to your record.

Transactional email services like SendGrid, Postmark, Mailgun, and Amazon SES. If your application sends transactional mail (password resets, receipts, account notifications) through one of these, set up domain authentication in the service. Each one offers a dedicated DKIM signing path and SPF guidance.

The SPF lookup limit problem. SPF has a hard limit of 10 DNS lookups per record. Each include: counts as one lookup. If you've got M365, HubSpot, Mailchimp, SendGrid, a signature service, and a couple of other tools, you can easily blow past 10 lookups, at which point SPF starts silently failing for everything. The fix is SPF flattening — tools like dmarcian, EasyDMARC, or PowerDMARC can collapse your includes into a flattened list of IP ranges that stays under the limit. This is one of the few cases in DNS where automation is actually safer than hand-editing, because the flattened list needs to be updated whenever any underlying service changes its IP ranges.

Setting up DMARC monitoring before you turn enforcement on

The single biggest mistake we see in DMARC deployments is teams who publish p=reject on day one without monitoring first, then watch their own mail flow break. DMARC enforcement is not something you turn on without preparation. The right deployment sequence takes four to six weeks and follows a graduated escalation pattern.

Week 1: Publish p=none with a reporting address. Set up your DMARC record with p=none and a valid rua= address. This tells every major mail provider to start sending you daily aggregate reports without taking any enforcement action. Mail flow stays exactly as it was; you're just adding observability.

Set the rua= address to a dedicated mailbox or distribution list — not your personal inbox. You'll get one XML report per day per receiving mail provider, which adds up to dozens of files per week even for a small domain.

Weeks 1-3: Set up a DMARC monitoring tool and review reports weekly. Raw DMARC XML is unreadable. You need a tool that parses and visualizes it. Several free or low-cost options exist: dmarcian has a generous free tier for small senders; Postmark DMARC Digests is completely free and emails weekly summaries; EasyDMARC and Valimail Monitor are more comprehensive paid platforms. For a typical mid-market B2B environment, Postmark DMARC Digests is enough to get started.

Each week, review the report and identify every distinct sending source. For each source, ask three questions: Is this a legitimate service we use? Is it authenticated correctly (passing both SPF and DKIM with alignment)? If not, what's the fix? Build a tracking sheet with one row per sending source, marked as "authenticated," "needs fix," or "unknown — investigate."

Week 4: Graduate to p=quarantine with a percentage rollout. Once you've identified and fixed every legitimate sending source, change your DMARC policy to:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1

The pct=25 means apply the policy to 25% of failing messages — partial enforcement that limits blast radius if something is still misconfigured. Watch reports for another week. If no critical mail is getting quarantined, raise to pct=50, then pct=100.

Weeks 5-6: Graduate to p=reject. Once p=quarantine; pct=100 has been running cleanly for at least a week, raise the policy to:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1

This is the target state. Failing mail will be rejected outright rather than quarantined. Your domain is now fully protected against spoofing, and your authentication setup is as strong as it can be.

Keep DMARC monitoring on indefinitely. New tools get added, IT changes get made, services rotate IP ranges. The monitoring is what keeps the setup working over time — without it, the configuration will drift and you'll be back where you started in 18 months.

The Quantum deliverability audit checklist

When we run a deliverability audit for a client at Quantum, we work through the same checklist every time. Here it is, condensed into something you can run against your own environment.

If every line is green, your deliverability foundation is solid. If any line is red, that's your priority fix. We typically find that mid-market B2B environments hit eight or nine out of twelve on a first audit, with the gaps clustered around third-party senders and DMARC enforcement level.

Email deliverability isn't a one-time project — it's an operational discipline that needs to live somewhere in your revenue operations function. Most teams don't have anyone explicitly accountable for it, which is exactly why it stays broken. If your team is running heavy outbound, sending transactional mail at scale, or running marketing automation, this deserves a quarterly review cycle and a named owner. Otherwise, the deliverability tax compounds quietly until someone notices a pipeline problem that traces back to spam folders.

And if you'd rather hand this off than tackle it internally, this is exactly the kind of work we do at Quantum as part of a broader revenue operations engagement.

Frequently Asked Questions