Subscribe to our newsletter
Authentication protocols are often treated like checkboxes. You set up SPF, DKIM, and DMARC, they validate, you’re done. Most teams do them correctly enough to pass basic validation.
We do something different. We review them line by line, beyond pass-fail.
What We’re Actually Looking For
When we audit your DNS setup, we’re not asking “does this work?” We’re asking “does this look legitimate when examined closely?” That’s a different question.
Consider SPF. The basic requirement is that your SPF record lists the IP addresses authorized to send on your behalf. That’s straightforward. You can generate one in minutes and it will work.
But what looks legitimate under enterprise inspection? A clean, minimal SPF record with a single source of truth. Explicit includes only for services you actually use. A “~all” or “-all” policy that’s intentional. SPF records that don’t have chaotic histories of abandoned services and obsolete entries.
An SPF record can pass validation and still look messy under inspection.
Here’s an example: Your SPF record has includes for Mailgun, SendGrid, Klaviyo, HubSpot, and ActiveCampaign. You’re only actively using Mailgun and SendGrid. The other three are old services you stopped using. The record technically works. But when an enterprise security team audits you, they see a messy record with abandoned services. That suggests poor governance.
We audit for coherence, not just function. Your SPF record should be clean, intentional, and reflect your current sending services. Not cluttered with historical baggage.
DKIM: Key Management and Rotation
DKIM is more complex than SPF because it involves cryptographic keys. You need to generate keys, publish them in DNS, and rotate them over time. Most teams set it up once and forget about it.
We handle DKIM key generation and publication. We set up keys that are properly sized and formatted. We document when they were created so you have a clear history. You have documented, traceable infrastructure, not just “it works.”
We also establish a rotation schedule. Keys don’t stay published forever. Over time, publishing records that include obsolete keys weakens your authentication. It also indicates poor maintenance to ISPs evaluating your credibility. We rotate keys on a reasonable schedule to keep your DKIM clean and current.
Example: You’ve been using the same DKIM key for five years. It still works. But ISP standards have evolved. Stronger key sizes are now expected. Your key looks outdated. We proactively rotate to a newer, stronger key. You’re always current, not just functional.
For most teams, DKIM is just “is it working?” For us, it’s “is it coherent and well-maintained?”
DMARC: Policy and Reporting
DMARC is the enforcement layer. Your DMARC policy tells ISPs what to do if an email claims to be from you but doesn’t authenticate. It’s your way of saying “I control my sending. If it doesn’t authenticate, block it.”
Most teams set DMARC to “p=none” (monitor only) and leave it there indefinitely. That’s technically safe but it’s not actually using DMARC. You’re collecting reports but not enforcing anything.
We help you evolve to stronger policies over time. We monitor DMARC reports to understand your authentication performance. We look at how many of your emails are authenticating properly. Once you’re consistently authenticating reliably, we can move to “p=quarantine” (filter suspicious mail) or “p=reject” (outright block spoofed mail).
This isn’t aggressive or risky. It’s the natural progression of a mature sender. As your authentication infrastructure matures, your policy can strengthen.
Here’s the sequence: Start at p=none to monitor. Stabilize at p=quarantine once you’re reliably authenticating. Move to p=reject once you have full confidence. That progression from permissive to strict is actually a signal of legitimate sender maturity to ISPs. It says “we’re careful, we test, we enforce standards.”
Coherent Sender Identity Under Inspection
The bigger picture is that your entire authentication setup tells a story. It says:
“I’m a legitimate organization that sends email intentionally. I’ve invested in infrastructure. I maintain it. I have policies. I’m not trying to hide or evade.”
When an enterprise security team inspects your DNS, that’s the impression they should get. Not “does this technically work?” but “is this a legitimate sender?” The difference matters.
That requires:
• Clean SPF with explicit, intentional includes (not abandoned services)
• Well-maintained DKIM with current keys (rotated on schedule)
• DMARC policy that reflects your actual sending pattern (and evolves as you mature)
• DNS records that are tidy and coherent (no abandoned entries, no chaos, no historical baggage)
• A clear mapping between your published records and your actual sending infrastructure
Example: An enterprise security team is evaluating you. They look at your DNS. It’s clean. Your SPF has three includes – all current services. Your DKIM keys are rotated on schedule. Your DMARC policy is at p=quarantine, which is the appropriate level of enforcement. Everything is documented and coherent. They see a legitimate organization managing their infrastructure responsibly.
Compare that to messy DNS with abandoned services and obsolete keys. Different impression. Different filtering outcome.
We build that coherence. Not just technically correct. Intentional and mature.
Periodic Audits Even When Nothing Changes
We audit your setup periodically. Standards change. ISP behaviors evolve. What was acceptable two years ago might be suboptimal now. The email industry moves faster than most people realize.
Maybe ISPs are starting to pay more attention to DKIM key strength. Maybe DMARC subdomain alignment has become more important. Maybe there’s a new best practice around SPF syntax. Maybe Gmail is applying stricter standards to authentication coherence.
Periodic audits catch these shifts. We keep your authentication current not just with technical standards but with evolving ISP expectations. You’re always aligned with current best practices, not yesterday’s acceptable practices.
We’d love to learn more about your business, email deliverability and outreach goals, and see if we might be able to help.
Whether you have questions about what we do, how Protocol works, or you’d just like to pick our brains on some of our best practices, we’d be happy to chat.
Schedule a call with our Revenue Director, Chrisley Ceme.
Authentication protocols are often treated like checkboxes. You set up SPF, DKIM, and DMARC, they validate, you’re done. Most teams do them correctly enough to pass basic validation.
We do something different. We review them line by line, beyond pass-fail.
What We’re Actually Looking For
When we audit your DNS setup, we’re not asking “does this work?” We’re asking “does this look legitimate when examined closely?” That’s a different question.
Consider SPF. The basic requirement is that your SPF record lists the IP addresses authorized to send on your behalf. That’s straightforward. You can generate one in minutes and it will work.
But what looks legitimate under enterprise inspection? A clean, minimal SPF record with a single source of truth. Explicit includes only for services you actually use. A “~all” or “-all” policy that’s intentional. SPF records that don’t have chaotic histories of abandoned services and obsolete entries.
An SPF record can pass validation and still look messy under inspection.
Here’s an example: Your SPF record has includes for Mailgun, SendGrid, Klaviyo, HubSpot, and ActiveCampaign. You’re only actively using Mailgun and SendGrid. The other three are old services you stopped using. The record technically works. But when an enterprise security team audits you, they see a messy record with abandoned services. That suggests poor governance.
We audit for coherence, not just function. Your SPF record should be clean, intentional, and reflect your current sending services. Not cluttered with historical baggage.
DKIM: Key Management and Rotation
DKIM is more complex than SPF because it involves cryptographic keys. You need to generate keys, publish them in DNS, and rotate them over time. Most teams set it up once and forget about it.
We handle DKIM key generation and publication. We set up keys that are properly sized and formatted. We document when they were created so you have a clear history. You have documented, traceable infrastructure, not just “it works.”
We also establish a rotation schedule. Keys don’t stay published forever. Over time, publishing records that include obsolete keys weakens your authentication. It also indicates poor maintenance to ISPs evaluating your credibility. We rotate keys on a reasonable schedule to keep your DKIM clean and current.
Example: You’ve been using the same DKIM key for five years. It still works. But ISP standards have evolved. Stronger key sizes are now expected. Your key looks outdated. We proactively rotate to a newer, stronger key. You’re always current, not just functional.
For most teams, DKIM is just “is it working?” For us, it’s “is it coherent and well-maintained?”
DMARC: Policy and Reporting
DMARC is the enforcement layer. Your DMARC policy tells ISPs what to do if an email claims to be from you but doesn’t authenticate. It’s your way of saying “I control my sending. If it doesn’t authenticate, block it.”
Most teams set DMARC to “p=none” (monitor only) and leave it there indefinitely. That’s technically safe but it’s not actually using DMARC. You’re collecting reports but not enforcing anything.
We help you evolve to stronger policies over time. We monitor DMARC reports to understand your authentication performance. We look at how many of your emails are authenticating properly. Once you’re consistently authenticating reliably, we can move to “p=quarantine” (filter suspicious mail) or “p=reject” (outright block spoofed mail).
This isn’t aggressive or risky. It’s the natural progression of a mature sender. As your authentication infrastructure matures, your policy can strengthen.
Here’s the sequence: Start at p=none to monitor. Stabilize at p=quarantine once you’re reliably authenticating. Move to p=reject once you have full confidence. That progression from permissive to strict is actually a signal of legitimate sender maturity to ISPs. It says “we’re careful, we test, we enforce standards.”
Coherent Sender Identity Under Inspection
The bigger picture is that your entire authentication setup tells a story. It says:
“I’m a legitimate organization that sends email intentionally. I’ve invested in infrastructure. I maintain it. I have policies. I’m not trying to hide or evade.”
When an enterprise security team inspects your DNS, that’s the impression they should get. Not “does this technically work?” but “is this a legitimate sender?” The difference matters.
That requires:
• Clean SPF with explicit, intentional includes (not abandoned services)
• Well-maintained DKIM with current keys (rotated on schedule)
• DMARC policy that reflects your actual sending pattern (and evolves as you mature)
• DNS records that are tidy and coherent (no abandoned entries, no chaos, no historical baggage)
• A clear mapping between your published records and your actual sending infrastructure
Example: An enterprise security team is evaluating you. They look at your DNS. It’s clean. Your SPF has three includes – all current services. Your DKIM keys are rotated on schedule. Your DMARC policy is at p=quarantine, which is the appropriate level of enforcement. Everything is documented and coherent. They see a legitimate organization managing their infrastructure responsibly.
Compare that to messy DNS with abandoned services and obsolete keys. Different impression. Different filtering outcome.
We build that coherence. Not just technically correct. Intentional and mature.
Periodic Audits Even When Nothing Changes
We audit your setup periodically. Standards change. ISP behaviors evolve. What was acceptable two years ago might be suboptimal now. The email industry moves faster than most people realize.
Maybe ISPs are starting to pay more attention to DKIM key strength. Maybe DMARC subdomain alignment has become more important. Maybe there’s a new best practice around SPF syntax. Maybe Gmail is applying stricter standards to authentication coherence.
Periodic audits catch these shifts. We keep your authentication current not just with technical standards but with evolving ISP expectations. You’re always aligned with current best practices, not yesterday’s acceptable practices.
Our Revenue Director, Chrisley Ceme, is leading the Triggered Outbound program.Chrisley’s gone deep on this strategy and can walk you through:
- How Triggered Outbound fits with your outbound goals
- What triggers are available (and what’s possible within our platform)
- Pricing, onboarding, and getting started
