fTLD DMARC: Email Security Best Practices for Financial Institutions
by
Last Updated: Reading Time: 6 min
Key Takeaways
- fTLD DMARC enforces strict authentication by combining SPF, DKIM, and DMARC alignment to validate legitimate senders.
- A p=reject policy is mandatory for all .BANK and .INSURANCE domains, blocking unauthorized email use.
- DMARC improves deliverability by enhancing domain reputation and ensuring trusted communications.
- Compliance supports financial cybersecurity regulations and reduces exposure to fraud-related financial loss.
- Ongoing report monitoring and vendor alignment ensure continuous protection and compliance across all email sources.
Every day, organizations send and receive countless emails, but not all of them are safe. For banks and insurance providers, keeping these messages secure is critical to protect both their clients and their reputation. Recognizing this need, in 2023, fTLD introduced DMARC for Public Suffix Domains (PSD) for the .BANK and .INSURANCE Top-Level Domains (TLDs) provide an automatic, registry-level layer of email protection.
What Is PSD DMARC?
Public Suffix Domains DMARC (PSD DMARC) is a security measure that applies baseline email authentication rules across all registered domains under TLDs, .BANK and .INSURANCE. Unlike traditional DMARC, which domain owners must implement individually, PSD DMARC operates at the registry level, ensuring consistent protection across every domain.
This development stems from standards set by the Internet Engineering Task Force (IETF) and is formally documented in RFC 9091. fTLD secured approval from the Internet Corporation for Assigned Names and Numbers (ICANN), enabling the implementation of this automatic safeguard.
What is fTLD?
fTLD Registry is the domain authority for .BANK and .INSURANCE. These are the most reliable and only exclusive domain extensions for banks, insurers, and producers. fTLD Registry aims to provide these domains with a strong shield against cyberattacks and fraud.
fTLD (.BANK / .INSURANCE) Domain Compliance Checklist
This checklist helps registrants comply with email authentication and encryption (TLS) requirements for fTLD domains as specified in official fTLD documents.
1. Email Authentication Requirements
Mandatory DNS Records
Publish a valid DMARC record for the domain (required whether or not the domain sends email). Publish at least one of the following:
- SPF (Sender Policy Framework) record
- DKIM (DomainKeys Identified Mail) record
DMARC Policy Requirements
| Domain Usage | Required DMARC Policy | Notes |
|---|---|---|
| Domain not used for sending email | p=reject | Prevents spoofed or invalid mail from being accepted |
| Domain used for sending email | p=reject (mandatory for ongoing operations) | Can start with p=none or p=quarantine during implementation, but must change to p=reject as soon as possible, and no later than 90 days |
Recommended DMARC Configuration
While not a requirement, fTLD recommends strict alignment for SPF and DKIM using: adkim=s and aspf=s tags. For organizational domains publishing DMARC, set an appropriate sp: tag to define subdomain policy.
Benefits of Configuration:
- Email authentication prevents spoofed or fraudulent emails claiming to be from your domain
- It increases trust and email deliverability
2. Encryption / Transport Layer Security (TLS) Requirements
Digital Certificate
- Obtain a valid TLS certificate for your domain and all subdomains.
- Ensure no prohibited cipher components are used (see list below).
HTTPS Enforcement
- Force all domain and subdomain traffic to HTTPS (encrypted).
- Any HTTP URLs must automatically redirect to HTTPS.
- Redirection must originate from the HTTPS version of the fTLD domain.
- The domain must be HTTPS-only (no unencrypted access).
| Connection Type | Requirement | Notes |
|---|---|---|
| Web connections | Maintain TLS v1.2 or higher | While lower versions may be temporarily used for educational content on browser hygiene and updates, we don’t recommend it. |
| Server-to-Server Email | Offer TLS v1.1 or higher at the highest priority | Lower versions (TLS/SSL or unencrypted) are permitted only when communicating with non-fTLD domains that don’t support encryption. |
| Other services | Use TLS v1.1 or higher | TLS v1.0 does not need to be disabled at this stage. |
| RFC 5746 (Transport Layer Security Renegotiation Indication Extension) | Must be implemented | Prevents a specific form of man-in-the-middle attack wherein an attacker establishes a TLS connection with the target server, inserts malicious content, and then merges it with a new TLS connection initiated by a client. |
Prohibited Cipher Suite Components
The guidelines advise against using or including any of the following in your TLS configurations or certificates:
Anon, CBC, DES, 3DES, FIPS, GOST 28147-89, IDEA, SEED, WITH_SEED, MD5, NULL, SHA1, RC4, EXPORT, EXPORT1024, SRP
Benefits of configuration
- Ensures secure, encrypted communication across web and email
- Prevents data tampering, interception, or eavesdropping
Quick Compliance Recap
- Publish and enforce DMARC (p=reject), plus SPF/DKIM
- Implement TLS v1.1+ across all services
- Redirect all HTTP to HTTPS
- Use approved cipher suites only
- Enforce DMARC policies within 90 days of email setup
Why DMARC Is Critical for fTLDs
DMARC is critical for financial domains due to the following benefits it provides:
Prevents Fraudulent Domain Use
A p=reject policy is a direct instruction to mail servers worldwide to block any email that fails authentication. This action effectively prevents criminals from directly spoofing a financial domain in phishing attacks.
Boosts Email Deliverability
A proper DMARC configuration improves sender reputation and promotes the reliable, hassle-free delivery of official communications.
Supports Regulatory Adherence
The financial sector is full of laws and regulations. DMARC serves as an important technical control that helps organizations satisfy cybersecurity requirements.
Reduces Exposure to Financial Loss
The prevention of email-based attacks helps an institution avoid the severe costs associated with data breaches, such as regulatory fines, remediation expenses, and reputational harm.
DMARC Implementation Best Practices
Email authentication implementation demands a methodical approach.
1. Don’t Rush to p=reject
The final configuration should be a policy of rejection (p=reject). However, this action should be done with caution, after a period of monitoring your domains on p=none and p=quarantine. Even fTLD guidelines offer a 90-day grace period before enforcement.
2. Confirm SPF and DKIM Alignment
Both SPF and DKIM require precise configuration for every authorized email source. The domains used in these authentication mechanisms must align with the “From:” domain that a customer sees.
3. Use DMARC Report Analysis Tools
DMARC generates aggregate (RUA) and forensic (RUF) reports that contain vital data about your domain’s email traffic, but are not intuitive or human-readable. A dedicated DMARC report analyzer parses this information to help you decipher and understand it better.
4. Align Internal and Vendor Email Policies
All third-party services that transmit email on behalf of your institution must conform to your authentication needs. Communication with these vendors about the same is critical.
Common Challenges
Organizations may face some technical hurdles during the DMARC adoption process.
The Discovery of Third-Party Senders
A comprehensive inventory of all external services that send email can be a complex undertaking for large organizations and enterprises with diverse technology stacks.
DNS Propagation Delays
DMARC, SPF, and DKIM are configured through DNS. Updates to these records require time to propagate across the internet, a factor that can introduce delays to the deployment timeline.
Management of DMARC Report Data
The raw XML data from DMARC reports is dense and voluminous. Analysis without a specialized platform is exceptionally difficult and inefficient.
Recommended Tools and Providers
The volume and complexity of DMARC data make manual management an impractical strategy. Specialized platforms are a necessity for effective oversight. Key features to look for in a provider include:
Intelligent Report Visualization
The platform must translate raw XML data into clear, actionable dashboards that show trends and threats.
Sender Identification
The service should automatically categorize email sources and provide clear guidance on the authentication steps required for each legitimate sender.
Proactive Threat Alerts
It’s also a major plus if the platform offers real-time notifications about authentication failures or new spoof attempts to enable a rapid security response.
At PowerDMARC, our platform provides a full suite of managed email authentication services. Our DMARC Analyzer transforms complex XML reports into human-readable charts for clear threat visibility. The PowerSPF tool dynamically optimizes complex SPF records to prevent validation errors and ensure all legitimate senders are authorized.
Additionally, we simplify the deployment of advanced standards like Hosted BIMI to display your logo in emails and MTA-STS to encrypt email in transit.
Final Thoughts
Ultimately, DMARC adoption is a core operational requirement for any institution on the .BANK and .INSURANCE TLDs. It is an indispensable technology for the defense of the institution’s brand, the protection of its customers, and the satisfaction of regulatory obligations.
The path to full compliance begins with a monitor-only policy to gain full visibility of the email landscape. From there, an organization can methodically authenticate its legitimate senders and advance to a final, enforced policy of rejection. Partnership with a DMARC service expert can de-risk this transition and ensure sustained security.
Ready to secure your financial domain? Explore our DMARC Compliance solution and start your journey to full enforcement today.
Frequently Asked Questions
How do fTLD DMARC requirements change things for my domain’s email?
How it affects you depends on your current setup:
- If you already have a DMARC record: Your existing email policies and reports will not change. PSD DMARC simply acts as a powerful backup.
- If you do NOT have a DMARC record: This is a huge security boost. The PSD DMARC policy gives email providers clear instructions on what to do with fraudulent emails. This protection applies to all your registered domains, including your primary website, parked domains, and any you own for defensive purposes.
Does fTLD DMARC change what data is collected from my email?
If you already have your own DMARC policy, your reporting data remains unchanged. The primary change is that fTLD may now receive high-level, aggregate reports for domains that aren’t actively published (like defensive registrations) or for spoofing attempts on domains that don’t exist. This data helps them monitor the health of the entire system.
How is fTLD using this data?
The goal is to protect the .BANK and .INSURANCE community. fTLD uses this aggregate data to spot emerging threats, identify malicious activity, enforce security compliance, and enhance the overall stability and safety of these TLDs.
Where can I find more info?
- The Technical Standard: You can read the official IETF specification, RFC 9091.
- More on PSD DMARC: Visit this official PSD DMARC documentation for additional resources.
fTLD’s Specific Rules: You can review the DMARC security requirements directly on the .BANK and .INSURANCE registry websites.
Domain & Email Security Expert at PowerDMARC
Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.
Latest posts by Yunes Tarada (see all)
- A Step-by-Step Guide to Setting Up SPF, DKIM, and DMARC for Wix - January 26, 2026
- How to Fix “Reverse DNS Does Not Match the SMTP Banner” Error - January 22, 2026
- What Is BIMI? Email Trust and Brand Identity - December 26, 2025
