In This Article
- The Email Authentication Trap Most FIs Don't Know They're In
- SPF, DKIM, and DMARC: The Three-Protocol Stack
- Why Microsoft's Default Anti-Spoof Protections Aren't Enough
- The 9-to-18-Month DMARC Enforcement Roadmap
- Five Pitfalls That Block Legitimate Mail at Financial Institutions
- The FFIEC, OCC, NCUA, and PCI DSS Compliance Lens
- Frequently Asked Questions
Most financial institutions believe their domain is protected from spoofing because Microsoft 365 has anti-spoof features turned on by default. That belief is wrong. Microsoft's default Composite Authentication and Spoof Intelligence are useful internal signals, but they are not a substitute for SPF, DKIM, and DMARC. They provide zero protection at Gmail, Yahoo, or any non-Microsoft mail server. They do not block a determined attacker who has aligned with even one of your sending sources. And they leave your customer-facing brand domain wide open to the kind of spoof that turns a $50,000 wire reversal into a regulatory disclosure and a cyber-insurance claim.
Email authentication for banks, credit unions, and mortgage companies is one of those subjects that sits at the intersection of three things engineers do not enjoy: DNS administration, regulatory interpretation, and cryptographic key management. It is also the single highest-leverage email-security control a financial institution can deploy. SPF and DKIM verify the sending infrastructure and the message contents. DMARC ties them together with a published policy that tells every receiving mailbox in the world what to do with mail that fails the check. When all three are configured correctly and DMARC is set to p=reject, an attacker can no longer send spoofed mail from your domain to anyone, anywhere, regardless of which mail server receives it.
The catch is that getting from "we have SPF" to "we are at p=reject with full enforcement" takes most financial institutions between nine and eighteen months when it is done correctly. Skipping phases, rushing the rollout, or treating DMARC as a checkbox guarantees blocked legitimate mail and an angry CFO whose payroll provider's notifications stopped reaching the inbox. This article walks through how the three protocols actually work, why Microsoft's defaults are insufficient, what a phased enforcement roadmap looks like for a financial institution, and the five operational pitfalls that derail rollouts most often.
The Email Authentication Trap Most Financial Institutions Don't Know They're In
The trap is set by what looks like good news. Microsoft 365 has anti-spoof protection enabled by default. Defender for Office 365 evaluates inbound mail against multiple signals, including SPF, DKIM, DMARC results from your sending domains, sender reputation, and Microsoft's internal Composite Authentication score. Most financial-institution IT teams see "anti-spoof: on" in the admin center, conclude that their domain is protected, and move on to the next problem.
What this analysis misses is the asymmetry of email authentication. Microsoft's anti-spoof signals operate inside Microsoft 365. They protect your inbox from inbound spoof attempts. They do not, and cannot, protect your domain from being spoofed when the attacker is sending mail to a customer at a different mailbox provider. If a fraudster spoofs your-bank.com in a wire-fraud lure aimed at a corporate treasury account holder whose company runs on Google Workspace, Microsoft's Composite Authentication is irrelevant. The receiving mail server is Gmail. Gmail evaluates SPF, DKIM, and DMARC. If your domain has not published proper authentication records and a DMARC policy of p=reject, Gmail has no way to know the message was spoofed.
Across the financial-institution tenants ABT's Guardian Managed Detection and Response team has investigated following spoof-driven incidents, the same pattern repeats. Microsoft 365's default anti-spoof features were enabled. The brand domain had a partial SPF record and either no DKIM or DKIM scoped to only one sending source. DMARC was either absent or published at p=none with no reporting address. The attacker's spoofed mail bypassed the protections that existed because those protections were not the ones that mattered. Defaults are not a security program.
Microsoft May 2025 Bulk-Sender Enforcement Is Already Live
As of May 5, 2025, Outlook and Hotmail rejected mail from senders pushing more than 5,000 messages a day if those senders had not implemented SPF, DKIM, and DMARC. The implication for financial institutions: any domain that sends customer statements, payment notifications, loan disclosures, or marketing email at high volume needs the full authentication stack right now, or those messages are silently failing to deliver. This is not a future regulatory deadline. It happened a year ago.
The opposite trap is also common. Some MSPs configure SPF and DKIM, publish a DMARC record at p=none for monitoring, and then stop. They report to the financial institution that "DMARC is implemented." From a compliance checklist perspective, that statement is technically true. From a protection perspective, it is meaningless. p=none blocks no spoofed mail. It only generates aggregate reports that show who is spoofing the domain. Those reports are valuable for moving toward enforcement, but if no one reads the reports and the policy never advances past p=none, the domain remains spoofable indefinitely while the institution believes it is protected.
SPF, DKIM, and DMARC: How the Three-Protocol Stack Actually Works
Email authentication did not emerge as a single coordinated standard. It evolved over a decade in three layers, each addressing a different gap in the prior layer. Understanding why three protocols exist, and what each one actually verifies, is the foundation for configuring them correctly. Misconfigurations almost always trace back to a misunderstanding of which protocol does what.
SPF (Sender Policy Framework, RFC 7208) verifies the sending infrastructure. A domain owner publishes a DNS TXT record that lists the IP addresses or hostnames authorized to send mail on behalf of the domain. When a receiving mail server gets a message claiming to be from your-bank.com, it checks the connecting IP against the SPF record. If the IP is on the list, SPF passes. If not, SPF fails. The check is binary.
DKIM (DomainKeys Identified Mail, RFC 6376) verifies the message itself. The sending mail server uses an asymmetric private key to generate a cryptographic signature over the message headers and body. The signature is attached to the message in a DKIM-Signature header. The receiving mail server retrieves the corresponding public key from a DNS TXT record published by the sender, then validates the signature. If the signature verifies, DKIM passes, and the receiver knows the message was not modified in transit and was signed by an entity in possession of the private key.
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) ties the two together with a published policy. DMARC requires that at least one of SPF or DKIM both passes and aligns with the visible From: address. Alignment means the authenticated domain matches the domain a human reader sees in their mail client. Without alignment, an attacker could pass SPF using their own infrastructure and still spoof your domain in the visible From. DMARC closes that gap by requiring the authenticated identity to match the displayed identity, then publishing a policy that tells receiving servers what to do when the alignment check fails.
RFC 7489 is explicit about what each policy value means. The text quoted below is from Section 6.3 of the specification, which defines the policy tag and the operational behavior receiving servers are expected to follow. The phrasing leaves no room for interpretation when a domain owner publishes p=reject: the receiving server is asked to refuse delivery.
The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. RFC 7489, Section 6.3, defining the
p=rejectpolicy.
DMARC's three policy values represent fundamentally different operational postures, not a sliding scale of protection. p=none instructs receivers to take no special action; failed mail still arrives in inboxes, but the domain owner receives daily aggregate reports identifying every IP address that sent claiming to be from the domain. p=quarantine instructs receivers to treat failed mail as suspicious, typically routing it to spam. p=reject instructs receivers to refuse delivery outright, returning a permanent failure to the sender. Only p=reject actually blocks spoofed mail at the transport layer. The other two policies are operational tools, not security postures.
The optional pct tag is widely misunderstood. Setting pct=25 alongside p=quarantine does not provide 25% of the security benefit of full enforcement. It instructs receivers to apply the quarantine policy to roughly 25% of the messages that fail alignment, while delivering the other 75% according to default rules. The percentage tag exists to enable gradual rollout (pushing more traffic into enforcement over time as confidence grows), not to provide partial protection. A domain at pct=25 is still 75% spoofable.
Why Microsoft's Default Anti-Spoof Protections Aren't Enough (CompAuth ≠ DMARC)
Microsoft 365 includes a Composite Authentication signal, abbreviated CompAuth, that combines SPF, DKIM, DMARC, and several behavioral indicators into a single internal verdict. Some MSPs and IT teams interpret this as a one-stop replacement for the three underlying protocols. The interpretation is wrong, and Microsoft's own documentation says so explicitly. CompAuth is a complement, not a substitute.
The mechanical reason CompAuth cannot replace SPF, DKIM, and DMARC is that CompAuth runs only inside Microsoft's mail flow. When a receiving server somewhere else evaluates mail claiming to be from your domain, it does not have access to Microsoft's internal verdict. It evaluates SPF and DKIM directly against your published DNS records, applies your DMARC policy, and routes the message accordingly. If your domain has no SPF record, has DKIM scoped only to one sender, or has no DMARC record at all, the external mail server has nothing to check, and your domain is spoofable from that server's perspective.
SPF, DKIM, and DMARC (Published Standards)
- Defined in IETF RFCs 7208, 6376, 7489 (vendor-neutral)
- Evaluated by every compliant mail server worldwide
- Protects mail going out to Gmail, Yahoo, corporate mail systems, government recipients
- Failure can be enforced at
p=reject, blocking spoofed mail before delivery - Reportable through aggregate (
rua) reports for visibility into sending sources - Required by PCI DSS 4.0.1 Section 5.4.1, expected by FFIEC anti-phishing guidance
Composite Authentication (Microsoft Internal)
- Proprietary to Microsoft 365 mail flow
- Provides zero protection at Gmail, Yahoo, corporate mail servers, or government mail systems
- Cannot be evaluated by any non-Microsoft receiver
- Documented by Microsoft as "not a replacement for SPF, DKIM, or DMARC"
- Useful as an additional inbound signal, not as the sole authentication control
- Does not satisfy regulatory expectations that reference DMARC by name
The takeaway is not that CompAuth is bad. It is a reasonable additional signal that Microsoft uses to score inbound messages, particularly to catch spoof attempts that pass DMARC because the attacker has aligned with one of the domain's sending sources but is otherwise behaving suspiciously. The takeaway is that CompAuth is downstream of SPF, DKIM, and DMARC. If those three protocols are not configured correctly, CompAuth has nothing to combine, and the domain is unprotected at every receiving system that is not running Microsoft 365.
Microsoft Defender for Office 365 includes the diagnostic tooling needed to validate SPF, DKIM, and DMARC alignment from real inbound traffic, including the Email Authentication detail page in the Threat Explorer interface and per-message authentication-results headers in quarantine. Financial institutions licensed for Defender for Office 365 already have the visibility they need to audit their authentication posture. The barrier to enforcement is not licensing or tooling. It is operational discipline: reading the aggregate DMARC reports week after week, cataloging every legitimate sender, and aligning each one before flipping the policy to enforce. Guardian's hardening baseline includes this monitoring discipline as a standard component, mapped to FFIEC and PCI DSS expectations.
The 9-to-18-Month DMARC Enforcement Roadmap
Email-authentication specialists who work at scale are nearly unanimous on this timeline. A financial institution moving from a published p=none record to full p=reject enforcement should expect nine to eighteen months when the rollout is done correctly, with each major phase lasting at least ninety days. Compressed timelines feel productive in planning meetings and create silent delivery failures in production.
The reason the timeline is long is the diversity of legitimate senders that the average financial institution discovers during the monitoring phase. The bank's own mail servers send mail. So does the marketing automation platform, the customer-statements service, the payroll provider, the loan-origination system, the helpdesk ticketing system, the security alerting platform, the BSA monitoring vendor's notification system, and the office printer that scans-to-email. Each one is a separate sending source that must be authenticated and aligned before enforcement starts. Skipping the discovery phase means rejecting some of those services as collateral damage when the policy advances.
Publish p=none with a valid rua aggregate-reporting address. Review reports daily. Catalog every legitimate sending source. Configure SPF and DKIM alignment for each one. Do not advance until alignment passes for at least 95% of legitimate mail across 30 consecutive days.
Move to p=quarantine starting at pct=10. Increase to pct=25 after two weeks if reports stay clean, then pct=50, pct=75, and finally pct=100. Pause and remediate at any percentage where legitimate mail starts failing. The goal is zero legitimate-sender breakage by the end of phase two.
Move to p=reject only after at least 30 days of clean reports at pct=100 quarantine. Continue monitoring aggregate reports indefinitely; new vendors and acquisitions can reintroduce alignment failures at any time. Reaching p=reject is the start of ongoing operations, not the finish line.
The percentages and durations above are not arbitrary. They are the result of an industry consensus built from large-scale rollouts where compressed timelines produced delivery failures that took weeks to diagnose and reputational harm that took longer to recover from. The single most common cause of enforcement failure is treating phase one as a paperwork exercise. Reading the aggregate reports is the work. Cataloging sending sources is the work. Configuring SPF and DKIM alignment for each one, including the office printer that nobody remembered, is the work. Phase one ends when the work is done, not when ninety days elapse on a calendar.
Key Takeaway
DMARC enforcement is an operational program, not a configuration project. The technical changes are small. The operational discipline of identifying every legitimate sender, configuring alignment for each one, and monitoring reports continuously is what determines whether the domain reaches p=reject in twelve months or breaks legitimate mail in three months and gets rolled back.
Five Pitfalls That Block Legitimate Mail at Financial Institutions
Across financial-institution DMARC rollouts that have stalled or failed, five operational pitfalls account for most of the damage. Each one has a specific remediation. Identifying them in advance shortens the rollout and prevents the mid-deployment surprises that erode confidence in the security program.
- SPF record exceeds the 10-DNS-lookup limit. RFC 7208 imposes a hard limit of 10 DNS lookups per SPF check, including lookups caused by the
includemechanism and by nested includes inside those includes. Exceeding the limit returns PermError, which causes SPF to fail for every message from the domain, including legitimate ones. The remedy is to audit the current SPF record, count lookups, consolidate or flatten where possible, and consider a managed SPF service that resolves to a single include. Alternatively, segment bulk-sending services to dedicated subdomains, each with its own 10-lookup budget. - DMARC record published with no
ruareporting address. A DMARC record atp=nonewith noruatag provides neither protection nor visibility. The domain owner sees no aggregate reports, learns nothing about who is spoofing the domain, and has no data to drive the move toward enforcement. The remedy is straightforward: add theruatag pointing to a monitored mailbox or DMARC-reporting service before doing anything else. - DKIM signing scoped only to a single sending source. If the bank's primary mail server signs with DKIM but the loan-origination system, the marketing platform, and the customer-statements service do not, three of the four major sending sources have no DKIM signature. SPF must carry the alignment requirement alone, which fails the moment any of those services is forwarded or routed through an intermediary. The remedy is to configure DKIM signing at every sending source, with each source publishing its own selector under the parent domain's DNS.
- Alignment misunderstood as authentication. A message can pass SPF or DKIM without aligning with the visible
From:address. SPF passes against theReturn-Pathdomain, which is often a third-party ESP's bounce domain. DKIM passes against the signing domain in thed=tag, which can also be a third-party ESP. DMARC requires that one of these authenticated domains match theFrom:domain that customers actually see. Configuring SPF or DKIM correctly without checking alignment is the most common source of "DMARC is failing but my mail is configured" tickets. - DKIM keys never rotated, or still at 1024-bit RSA. RFC 6376 set 1024-bit RSA as the historical minimum, but the 2026 industry standard for DKIM signing is 2048-bit RSA. Microsoft, Google, and Yahoo expect it; cryptanalytic capabilities have advanced enough that 1024-bit keys are no longer considered adequate for long-lived signing. Keys should also rotate every three to six months. The remedy is to generate a new 2048-bit key under a fresh selector, publish the public key in DNS, transition signing to the new selector, and retire the old one only after confirming all traffic has migrated.
p=reject with 100% enforcement. Roughly 69.6% of domains have no effective DMARC protection at all. The financial-services sector trends higher than the global average, but a 2026 analysis of the top 100 global banks still found wide gaps between the largest institutions and mid-sized regional banks, credit unions, and mortgage companies.Find out where your tenant stands before your next examination
A Security Grade walks through your Microsoft 365 configuration in plain language, including SPF, DKIM, DMARC, and the rest of the controls FFIEC and OCC examiners look for. No sales call required to see the result.
Get Your Security Grade Talk to an ExpertThe FFIEC, OCC, NCUA, and PCI DSS Compliance Lens
Email authentication is no longer a nice-to-have hidden inside an internal IT roadmap. Federal regulators, payment-industry standards, and state privacy laws now reference DMARC, SPF, and DKIM as elements of reasonable security. The specific language varies. Some sources mandate the controls explicitly. Others reference them as expected elements of an anti-phishing program. The direction is uniform. Examiners increasingly expect to see the records published, the policy advancing, and the reports being read. For a deeper look at how examiners evaluate community-bank security programs as a whole, our walkthrough of building a security program beyond Secure Score covers the broader posture that email authentication sits inside.
| Source | Reference | What It Says About Email Authentication |
|---|---|---|
| NIST | SP 800-177 Revision 1 (Trustworthy Email) | Federal baseline for email security. Addresses SPF, DKIM, and DMARC as core components of trustworthy email. Published February 2019; remains the current authoritative federal guidance with no superseding revision as of April 2026. |
| FFIEC / OCC | OCC Bulletin 2021-36, Authentication and Access | References DMARC verification as an example of anti-phishing controls financial institutions should enable. Recommends external-mail banners as a complementary user-facing control. |
| NCUA | Cyber Incident Notification (effective Sept 2023) | Federally insured credit unions must report reportable cyber incidents within 72 hours. Spoof-driven business email compromise that produces unauthorized access or substantial operational impact qualifies. Email authentication is the most direct preventive control for the most common BEC vector. |
| PCI DSS | Version 4.0.1, Section 5.4.1 (effective March 31, 2025) | Anti-spoofing controls including DMARC, SPF, and DKIM are required for organizations in the payment-card ecosystem. The shift from "best practice" to "required" closes a long-standing gap. |
| FTC | Safeguards Rule (data-breach notification effective May 2024) | Does not name DMARC explicitly but treats reasonable security measures as a baseline. State regulators and the FTC increasingly view email authentication as part of what reasonable means in 2026. |
| Federal Reserve | FRB Services fraud-mitigation analysis (December 2025) | Identified business email compromise as a leading cause of fraudulent wire transfers from business deposit accounts, accounting for 73% of certain fraudulent wire transfers in the analyzed sample. |
Two additional dynamics make 2026 the year financial institutions cannot continue to defer email authentication. First, the major mailbox providers (Microsoft, Google, Yahoo) have moved from documentation to enforcement. Microsoft's May 2025 high-volume-sender requirements rejected unauthenticated bulk mail in Outlook and Hotmail. Google and Yahoo's 2024 bulk-sender rules already require SPF, DKIM, and DMARC for senders sending to Gmail and Yahoo Mail at any meaningful volume. Customer-statement deliverability now depends on authentication, regardless of regulatory posture.
Second, business email compromise is the attack pattern that most directly exploits inadequate authentication. The device-code phishing campaigns targeting financial institutions and the Teams helpdesk-impersonation chains we have analyzed both rely on convincing recipients that mail came from a legitimate internal source. Strong domain authentication does not stop every step of those attacks, but it removes the easiest vector (straight domain spoofing) and forces attackers into the higher-friction approaches that defenders can detect more reliably.
A Note on BSA, AML, and Records Retention
Mail subject to BSA record-retention obligations does not stop being subject to those obligations because it failed DMARC and was rejected. If an institution begins enforcing p=reject on its own outbound domain, it must verify that internal communications subject to BSA five-year retention are being preserved before the rejection occurs, not after. Most institutions handle this naturally because internal mail authenticates correctly and is never rejected; the edge case is unusual sending paths or vendor-relay setups where this assumption fails.
Closing the Authentication Gap
The path forward for a financial institution that has not yet reached p=reject is straightforward in concept and demanding in execution. Audit the current SPF, DKIM, and DMARC posture. Identify every legitimate sending source. Configure SPF and DKIM alignment for each one. Publish DMARC at p=none with a monitored rua address. Spend ninety days reading reports and closing alignment gaps. Move to p=quarantine at pct=10 and ramp gradually. Reach p=reject only after thirty days of clean reports at pct=100 quarantine. Then continue monitoring forever, because new vendors and infrastructure changes will keep introducing new alignment problems.
The institutions that succeed treat DMARC as an operational practice integrated into change management for every email-touching system. The institutions that fail treat DMARC as a project to be completed and forgotten. The middle category, those that publish a record and then stop, gets the worst of both worlds: a compliance checkbox they can show an examiner, and a domain that remains spoofable in practice. The work is real. The protection from doing the work is real. There is no shortcut.
Key Takeaway
Email authentication is foundational infrastructure for every financial institution that sends mail to customers, regulators, business partners, or employees outside its own walls. Microsoft's defaults are useful as additional inbound signals, not as the protection layer. Reaching p=reject is the goal. The path is nine to eighteen months of discovery, alignment, and gradual enforcement, supported by aggregate reports that someone is actually reading. Done correctly, it eliminates the most common attack vector in the highest-loss fraud category banks, credit unions, and mortgage companies face.
Frequently Asked Questions
SPF, DKIM, and DMARC each verify a different element of email authentication. SPF (Sender Policy Framework, RFC 7208) verifies that the connecting IP address is authorized to send mail on behalf of the domain. DKIM (DomainKeys Identified Mail, RFC 6376) verifies that the message content has not been modified in transit by checking a cryptographic signature attached to the message. DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) ties SPF and DKIM together with a published policy, requiring that at least one of them passes and aligns with the visible From address, then telling receiving mail servers what to do with messages that fail. All three protocols are needed; SPF or DKIM alone do not protect against domain spoofing.
Not in the way most teams expect. The p=quarantine policy instructs receiving mail servers to treat messages that fail DMARC alignment as suspicious, typically routing them to spam rather than blocking them. Spoofed messages still reach the recipient's mailbox, just in a less prominent folder. Sophisticated phishing campaigns often work precisely because users review their spam folder. Only p=reject actually causes receiving mail servers to refuse delivery of unauthenticated mail. The optional pct tag, when set to a value below 100, applies the policy to a percentage of failing messages and lets the rest through normally; this enables gradual rollout but does not provide proportional protection. A domain at p=quarantine pct=25 is still 75% spoofable.
Most financial institutions need nine to eighteen months to move from a published p=none policy to full p=reject enforcement, with each major phase lasting at least ninety days. Phase one publishes p=none with a valid rua reporting address and uses ninety or more days to identify every legitimate sending source and configure SPF and DKIM alignment for each one. Phase two moves to p=quarantine and ramps the pct tag gradually from 10 percent to 100 percent over ninety to one hundred twenty days. Phase three moves to p=reject only after thirty consecutive days of clean reports at pct=100 quarantine. Compressed timelines are the most common cause of blocked legitimate mail and damaged sender reputation; the discipline of working the phases in order pays off in lower business disruption.
No. Microsoft's documentation states explicitly that Composite Authentication, abbreviated CompAuth, is a complement to SPF, DKIM, and DMARC, not a replacement. CompAuth is internal to Microsoft 365 mail flow and provides no protection at Gmail, Yahoo, corporate mail systems running other platforms, or any other non-Microsoft receiver. A domain that relies on CompAuth without configuring SPF, DKIM, and DMARC remains spoofable from every receiving system that is not Microsoft 365. CompAuth is useful as an additional inbound signal that combines authentication results with reputation and behavioral data, but it presupposes that SPF, DKIM, and DMARC are configured correctly so that CompAuth has accurate signals to combine.
RFC 7208 imposes a hard limit of 10 DNS lookups per SPF check. Lookups counted include those caused by the include, a, mx, ptr, and exists mechanisms, plus any nested lookups that those mechanisms generate. When the limit is exceeded, SPF evaluation returns a PermError result, which is treated as an SPF failure. Every message from the domain effectively fails SPF until the record is fixed, which usually causes DMARC to fail as well unless DKIM alignment is independently passing. The remedy is to audit the current SPF record and count lookups, consolidate or flatten where possible, segment bulk-sending services to dedicated subdomains with their own SPF records, or use a managed SPF service that resolves to a single include while maintaining the underlying authorized-IP list.
FFIEC does not mandate DMARC by name as a hard regulatory requirement, but FFIEC guidance treats DMARC as an expected element of a layered email-security program. OCC Bulletin 2021-36, the FFIEC's interagency guidance on Authentication and Access to Financial Institution Services and Systems, references DMARC verification specifically as an example of anti-phishing controls that financial institutions should enable. Examiners increasingly expect to see published SPF, DKIM, and DMARC records, an active monitoring program, and a documented enforcement roadmap as part of reasonable email-security safeguards. NIST SP 800-177 Revision 1 is the federal baseline that the FFIEC examination framework references for trustworthy email. PCI DSS 4.0.1 Section 5.4.1, which applies to financial institutions in the payment-card ecosystem, requires anti-spoofing controls including DMARC, SPF, and DKIM as of March 31, 2025.
Industry guidance for large organizations recommends rotating DKIM keys every three to six months as a standard cadence. Keys should also rotate immediately under specific conditions: if a key is suspected to have been compromised, if the institution stops working with a third-party vendor that had access to the private key, when employees with access to email signing systems leave the organization, or when the institution migrates to a new email platform. The 2026 industry standard is RSA 2048-bit signing keys; institutions still using RSA 1024-bit keys should rotate to 2048-bit as part of their next scheduled rotation. The rotation process involves generating a new key pair, publishing the public key in DNS under a fresh selector, transitioning sending systems to the new selector, and retiring the old selector only after confirming all legitimate traffic has migrated successfully.
Ready to plan your DMARC enforcement roadmap?
ABT helps banks, credit unions, and mortgage companies move from p=none to p=reject without breaking legitimate mail. Talk to an expert about scoping your discovery phase, identifying every legitimate sending source, and building the operational practice that keeps DMARC working long after the rollout.
