5. Create DMARC and SPF records for email authentication

WHY THIS IS IMPORTANT

Having SPF & DMARC (at "p=reject") records ensures that only your bank, and those you authorize, can send email as your bank, protecting against phishing and spoofing, and increasing the deliverability of email to your customers.

GET HELP

• Email Security Providers  .BANK | .INSURANCE
• Check with Your Registrar

 
ADDITIONAL REQUIREMENT DETAIL

Registrants that have met requirements #1 and #2, and therefore appear in the .BANK or .INSURANCE zone, must publish a valid DMARC record whether or not the domain is used to send emails. If a vendor sends email on your behalf, sending with your *.BANK or *.INSURANCE domain email address, they must comply with Security Requirement 6, Implementing TLS; DNSSEC is not required.

For a domain not used for sending email: Registrants must publish a DMARC record with a reject mail receiver policy (p=reject). It is also recommended, as a best practice, to add an SPF record that authorizes no organizations to send on your behalf, i.e.,: "v=spf1 -all" as this sends a clear message that the domain isn't active regarding email.

For a domain used to send email: Registrants must publish a DMARC record with a reject mail receiver policy (p=reject), except during the implementation phase of email as described below*. In addition, Registrants must publish an Sender Policy Framework Record (SPF). While publishing a DomainKeys Identified Mail Record (DKIM) is not required, publishing both SPF and DKIM records creates additional security for your email channel. 

It is recommended that DMARC records specify strict identifier alignment for SPF and DKIM (if applicable) via the adkim and aspf tags. Also, for DMARC records published at an organizational domain level to set an appropriate sp: tag. 

*When deploying DMARC during the implementation phase of email capabilities, Registrants may temporarily use a “none” (p=none) or “quarantine” (p=quarantine) mail receiver policy, but must change the policy to reject for ongoing operations within 90 days of deployment.

Tip: Ensure that your organization’s incoming mail service provider/server is properly configured for DMARC and this is on top of having properly formed DMARC and SPF records. For common mail service providers like Gmail, Microsoft 365 (for inbound email only), and Yahoo!, they do this for you. If you use Microsoft 365 with a custom domain or an on-premise Exchange server, you’ll need to manually implement DMARC for your outbound mail (learn more about this here). 

SPF Practical Limitation (10 DNS Lookups Maximum)

A single SPF record can contain a maximum of 10 DNS lookups to see if you authorize a particular IP address to send mail on your behalf. This practical limitation should be observed to ensure timely delivery of email messages and favorable inbox ratings. There are several ways to avoid this limitation such as:

• Make use of sub-domains as each is afforded its own 10 lookup max
• Use separate email address (e.g., corporate, marketing)
• Send mail from different domains and/or IP addresses

Best Practices for reducing/avoiding too many lookups