Hardening Domain Reputation: A CLI Guide to Implementing SPF, DKIM, and DMARC for Indian Startups
During a recent audit of a Bengaluru-based fintech startup, we discovered that 40% of their outbound transactional emails were being flagged as spam by Gmail and Outlook. The root cause was not the content, but a misconfigured SPF record that exceeded the 10-lookup limit due to nested "include" statements from multiple SaaS vendors. This is a recurring pattern in the Indian startup ecosystem, where rapid scaling often leads to "DNS debt." Hardening DNS security is the first line of defense against SMTP smuggling and brand impersonation.
What is DNS Security? Understanding the Meaning and Importance
DNS security refers to the set of protocols and practices designed to protect the Domain Name System from manipulation and to use DNS records to authenticate legitimate communication. In the context of email, it involves cryptographically signing messages and defining authorized sending sources. We view DNS not just as a directory service, but as a critical security layer that dictates the trustworthiness of your digital identity.
Defining DNS Security: How it Protects Your Network
DNS security protects your network by ensuring that the mapping between human-readable domain names and IP addresses remains untampered. Without mechanisms like DNSSEC (Domain Name System Security Extensions), attackers can perform cache poisoning, redirecting your traffic to malicious servers. For Indian startups handling sensitive financial data under the DPDP Act 2023, ensuring data integrity starts at the DNS level. When we implement SPF (Sender Policy Framework), we are explicitly telling receiving mail servers which IP addresses or CIDR blocks are authorized to send mail on our behalf.
DKIM (DomainKeys Identified Mail) adds another layer by providing a digital signature to the email header. This signature is verified against a public key stored in your DNS records. If an attacker modifies the email content during transit—a technique often used in "Man-in-the-Middle" (MITM) attacks—the DKIM verification will fail. This protects against the unauthorized modification of transaction details or payment links in emails, a common vector for UPI-related fraud in India.
The Role of DNS in Modern Cybersecurity
In modern cybersecurity, DNS acts as a telemetry source and a control point. By monitoring DNS queries, we can identify compromised internal hosts attempting to communicate with Command and Control (C2) servers. For an organization, the DNS records you publish determine how the rest of the world perceives your security posture. A missing DMARC (Domain-based Message Authentication, Reporting, and Conformance) record is often seen by automated reconnaissance tools as a green light for phishing campaigns, a threat vector frequently highlighted in the OWASP Top 10.
- Authentication: Proving that the sender is who they claim to be.
- Integrity: Ensuring the message has not been altered in transit.
- Visibility: Using RUA (Aggregate) and RUF (Forensic) reports to see who is sending mail using your domain.
- Policy Enforcement: Instructing mail servers to reject or quarantine unauthorized emails.
Common DNS Vulnerabilities and Why They Matter
We frequently encounter CVE-2023-51764, known as SMTP Smuggling, which is documented in the NIST NVD. This vulnerability exploits differences in how outbound and inbound SMTP servers interpret end-of-data sequences. If your DMARC policy is set to p=none, an attacker can smuggle a fraudulent email through a legitimate outbound server, and the inbound server will treat it as a verified message. This bypasses SPF and DKIM checks because the "envelope" appears legitimate.
Another major risk in the Indian SME sector is the use of outdated Exim Mail Transfer Agents (MTAs). CVE-2020-28018 (part of the "21 Nails" suite) allows for Remote Code Execution (RCE). Many Indian shared hosting providers run these vulnerable versions. If your DNS points to a vulnerable MTA, your entire domain reputation is at risk, regardless of how strong your SPF records are. This is why we recommend following an SSH security hardening best practices guide for all public-facing infrastructure. Attackers can use your server to send millions of spam emails, landing your domain on global RBLs (Real-time Blackhole Lists).
Evaluating Your Infrastructure: DNS Security Checks and Tests
Before implementing changes, we must baseline the current state of the domain. We use a combination of standard CLI tools and specialized network scanners to identify gaps in the DNS configuration. Testing should be performed from an external perspective to simulate how a remote mail server sees your domain.
How to Perform a DNS Security Test
We start by querying the existing TXT records for the domain. This reveals the current SPF and DMARC configurations. Use the dig command to pull these records directly from the authoritative name servers. We prefer dig over nslookup for its more detailed output and ability to specify query types easily.
Querying SPF records
$ dig +short TXT example.com | grep "v=spf1"
Querying DMARC records
$ dig +short TXT _dmarc.example.com
If the output is empty, the domain has no protection. If the SPF record contains too many "include" statements, we use a recursive script to count the DNS lookups. Exceeding 10 lookups causes a "PermError," which often results in SPF being ignored by modern filters. We also use nmap to check for open relays and vulnerable SMTP configurations on the mail servers pointed to by the MX records.
Scanning mail servers for vulnerabilities and open relays
$ nmap -p 25,465,587 --script smtp-commands,smtp-enum-users,smtp-open-relay
Key Metrics for a Comprehensive DNS Security Check
When we evaluate a domain, we look at several critical metrics that define the robustness of the DNS security implementation. These metrics are not just "pass/fail" but indicate the maturity of the security operations. For Indian startups, maintaining a high sender score is vital for customer acquisition and retention.
- DMARC Enforcement Level: Is the policy
p=none,p=quarantine, orp=reject? Onlyp=rejectprovides real protection. - SPF Lookup Count: Total number of DNS lookups required to resolve the SPF record. We aim for < 8 to provide a buffer.
- DKIM Key Length: We check if the keys are 1024-bit or 2048-bit. 1024-bit keys are increasingly vulnerable to brute-force attacks.
- DNSSEC Presence: Whether the zone is signed to prevent DNS hijacking and cache poisoning.
- Alignment: Whether the "From" header domain matches the SPF and DKIM domains (Strict vs. Relaxed alignment).
Identifying Vulnerabilities in Your Domain Name System
Vulnerabilities often hide in legacy records. We frequently find old SPF entries pointing to decommissioned marketing platforms or former employees' personal mail servers. These are "hanging entries" that an attacker can take over if the underlying IP address or domain is re-registered. This is a form of subdomain takeover that specifically targets email reputation.
To identify these, we perform a "shadow DNS" audit. We compare the records in the DNS control panel with the actual traffic patterns observed in DMARC reports. If the reports show legitimate mail coming from an IP not in the SPF, the record is incomplete. If the SPF includes an IP that hasn't sent mail in 90 days, it's a security risk and should be removed. We use swaks (Swiss Army Knife for SMTP) to test how our records are interpreted by a receiving server.
Testing SPF/DMARC by attempting to send a spoofed email
$ swaks --to [email protected] --from [email protected] --server mail.example.com --body 'Test Phish' --header 'Subject: Security Alert'
Comprehensive DNS Security Solutions and Services
Implementing SPF, DKIM, and DMARC is not a "set and forget" task. It requires ongoing management and a suite of tools to handle key rotation, report analysis, and policy updates. For startups, we recommend starting with open-source tools and graduating to managed services as the volume of outbound mail increases.
Essential Features of DNS Security Tools
Any tool used for DNS security must provide granular visibility into mail streams. We look for tools that can aggregate RUA reports and present them in a human-readable format. Raw DMARC reports are XML files that are difficult to parse manually. A good solution should highlight which IPs are failing authentication and why.
Key features include:
- Automated SPF Flattening: This solves the 10-lookup limit by dynamically replacing "include" statements with a list of IP addresses.
- DKIM Key Management: Automated rotation of DKIM keys to minimize the impact of a compromised private key.
- BIMI Support: Brand Indicators for Message Identification (BIMI) allows your logo to appear in the recipient's inbox, but it requires a
p=rejectDMARC policy. - Alerting: Real-time notifications when a new high-volume IP starts sending mail using your domain.
Managed DNS Security Services vs. In-House Management
In-house management gives you total control but is labor-intensive. We often set up OpenDKIM on Linux mail servers for startups that want to avoid monthly SaaS fees. This involves generating keys and configuring the MTA to sign outgoing mail. For a startup with limited DevOps resources, the risk of misconfiguration is high. Implementing a browser based SSH client can reduce the complexity of managing remote servers while maintaining strict security controls.
Generating a 2048-bit DKIM key pair with OpenDKIM
$ opendkim-genkey -t -s 2024_selector -d example.com
Extracting the public key for the DNS TXT record
$ cat 2024_selector.txt
Managed services like Cloudflare DNS, dmarcian, or OnDMARC automate the parsing of XML reports. In the Indian context, where compliance with the DPDP Act 2023 is mandatory, having a documented history of DMARC reports can serve as evidence of "reasonable security practices" to protect user data from phishing-based breaches. If the startup can afford ₹5,000 - ₹15,000 per month, a managed service is usually the better ROI.
How DNS Security Solutions Prevent Data Exfiltration
DNS security isn't just about email; it's also about preventing data exfiltration via DNS tunneling. Attackers can encode sensitive data into DNS queries (e.g., encoded-data.attacker.com). Advanced DNS security solutions use behavioral analysis to detect these patterns. By implementing a "DNS Sinkhole," we can redirect queries for known malicious domains to a controlled internal IP for analysis.
We also implement "Response Policy Zones" (RPZ). This allows us to override DNS responses for specific domains at the recursive resolver level. If a startup's employee clicks a link in a phishing email that points to malicious-site.in, which might use a URL validation bypass to appear legitimate, the internal DNS server can be configured to return 127.0.0.1, effectively neutralizing the threat before the connection is ever established.
Leading Enterprise DNS Security Vendors
For larger organizations or startups that have moved beyond basic hosting, enterprise-grade hardware and cloud-native solutions offer deeper inspection and integration. These vendors provide DNS security as part of a broader Secure Access Service Edge (SASE) or Next-Generation Firewall (NGFW) strategy.
DNS Security with Palo Alto Networks: Advanced Threat Prevention
Palo Alto Networks integrates DNS security directly into their PAN-OS. They use machine learning to identify "Domain Generation Algorithms" (DGA) in real-time. This is particularly effective against ransomware that uses DGA to find its C2 server. We've observed that Palo Alto’s DNS Security subscription can block 80% of new malicious domains before they are even categorized by standard web filters.
The implementation involves configuring the firewall as a DNS proxy. This allows the device to inspect every query and response. For an Indian enterprise, this provides a centralized point of control for all branch offices, ensuring consistent security policies regardless of the local ISP's DNS reliability. It also helps in complying with CERT-In mandates for reporting cyber incidents by providing detailed logs of attempted malicious DNS resolutions.
Implementing DNS Security via SonicWall Infrastructure
SonicWall’s approach often focuses on their Capture Labs threat intelligence. Their firewalls can perform DNS filtering based on category and reputation. This is a cost-effective solution for many Indian SMEs. We configure SonicWall to block "Newly Registered Domains" (NRDs), as these are statistically more likely to be used for phishing campaigns. A domain registered less than 24 hours ago is blocked by default until it can be verified.
We also utilize SonicWall's "DNS Rebinding" protection. This prevents a malicious website from using the victim's browser as a proxy to attack other devices on the internal network. By enforcing strict DNS response validation, we mitigate a whole class of browser-based attacks that target internal IoT devices or unauthenticated management interfaces.
Cloud-Native Protection with Zscaler DNS Security
Zscaler is a purely cloud-native solution, making it ideal for the "work from anywhere" model prevalent in the Indian tech scene. Since Zscaler sits between the user and the internet, it intercepts all DNS traffic. This is highly effective at preventing data exfiltration via DNS, as it can inspect the payload of the DNS queries themselves, not just the destination.
Zscaler's DNS security also includes protection against "bitsquatting" and "typosquatting." If a developer at a fintech startup accidentally types githun.com instead of github.com, Zscaler can block the request or redirect the user to a warning page. This prevents the accidental download of malicious packages or the leak of API keys to a typosquatted domain.
Best Practices for Implementing DNS Security Tools
Implementation should be iterative. We never move a domain to p=reject on day one. A phased approach prevents the accidental blocking of legitimate business communications, such as HR systems or automated billing platforms that might be sending mail on the startup's behalf.
Integrating DNS Protection into Your Broader Security Stack
DNS logs should be ingested into your SIEM (Security Information and Event Management) system. We use the ELK stack or Splunk to correlate DNS queries with other logs. For instance, if an endpoint shows an unusual spike in DNS traffic followed by a large outbound data transfer on port 443, we can quickly identify it as a potential exfiltration event. Integration with EDR (Endpoint Detection and Response) tools allows for the automatic isolation of hosts that query known malicious domains.
Furthermore, your DNS security policy must align with your Identity and Access Management (IAM) strategy. Only a limited number of administrators should have the authority to change DNS records. We recommend enabling Multi-Factor Authentication (MFA) and "Registry Lock" on your domain registrar account to prevent "Domain Hijacking," where an attacker gains control of your entire DNS zone by compromising a single account.
Configuring DNSSEC and Other Security Protocols
DNSSEC is often overlooked because of its perceived complexity. However, it is essential for preventing "DNS Hijacking" at the ISP level. We implement DNSSEC by signing the zone and then providing the Delegation Signer (DS) record to the domain registrar. This creates a chain of trust from the root zone down to your specific records.
In addition to DNSSEC, we are seeing a shift towards DNS over HTTPS (DoH) and DNS over TLS (DoT). These protocols encrypt the DNS query itself, preventing local network eavesdroppers or ISPs from seeing what domains your users are visiting. For Indian startups concerned about corporate espionage or ISP-level tracking, DoT is the preferred standard for internal infrastructure.
Monitoring and Responding to DNS-Based Attacks
Monitoring is the most critical phase. We monitor DMARC reports for "alignment failures." An alignment failure occurs when the domain in the "From" header doesn't match the domain validated by SPF or DKIM. This is a classic sign of a spoofing attempt. We use the following DMARC record configuration to start monitoring without impacting mail delivery:
Recommended DMARC policy for the monitoring phase
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r;
Once we have confirmed that all legitimate mail sources are correctly configured (usually after 30-60 days), we move the policy to p=quarantine and finally to p=reject. When p=reject is active, the DMARC record should look like this:
Hardened DMARC policy for enforcement
v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s;
The adkim=s and aspf=s tags indicate "strict" alignment, meaning the domains must match exactly, not just share a base domain. This is the highest level of protection against subdomain spoofing.
If you suspect a DNS-based attack is in progress, the first step is to check the serial number of your SOA (Start of Authority) record to see if any unauthorized changes were made. You can use dig to compare the records across different global DNS resolvers to check for propagation issues or localized cache poisoning.
Checking SOA serial number
$ dig +short SOA example.com
Comparing records across different resolvers (Google vs. Cloudflare)
$ dig @8.8.8.8 TXT example.com $ dig @1.1.1.1 TXT example.com
For Indian startups, the cost of a domain reputation hit can be measured in millions of Rupees in lost trust and missed opportunities. By treating DNS as a core security component rather than a background service, you build a resilient foundation that can withstand the evolving threat landscape of the Indian digital economy.
To verify if your current DKIM public key is correctly formatted for DNS, you can use OpenSSL to convert the private key to the DER format and then to base64, which is how it appears in the TXT record. This cross-check ensures that the key you published matches the key your mail server is using for signing.
$ openssl rsa -in 2024_selector.private -pubout -outform der | base64 -w 0