Assign this task
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.
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
- Full fTLD DMARC/SPF/DKIM Documentation
- The IETF RFC for DMARC
- Email Authentication Best Practices
CHECK YOUR WORK
To test your email server's TLS encryption, the following tool will provide information about the configuration of your email server and whether it is using strong encryption practices:
Tools to evaluate the configuration of your Domain-based Message Authentication, Reporting & Conformance (DMARC) and Sender Policy Framework (SPF) records:
- Valimail Email Authentication Testing Tool | DMARC & SPF
- dmarcian | DMARC Inspector
- dmarcian | SPF Record Check
- DMARC Analyzer | SPF Record Check
- MX Toolbox | DMARC Record Check
- MX Toolbox | SPF Record Check
Tools to validate your DKIM record: