DNSApe | Fast Network Tools

Settings

Winter snow effect

Email Security Report

Email Security

Email security protocols (SPF, DKIM, DMARC) work together to authenticate email senders and prevent spoofing. They help receiving mail servers verify that messages claiming to be from your domain are legitimate.

Common Uses

Prevent attackers from sending phishing emails that appear to come from your domain
Improve email deliverability by proving sender authenticity to receiving servers
Receive reports about emails sent using your domain name
Protect your brand reputation from abuse

Diagnostic Value

Identify missing or misconfigured email authentication records
Detect overly permissive SPF policies that allow spoofing
Find DKIM keys that may be weak or in test mode
Verify DMARC policy enforcement levels

History

Email was designed in the 1970s-80s without authentication - anyone could claim any sender address. SPF emerged in 2003, DKIM in 2007, and DMARC in 2012 to address this fundamental security gap. Today, major email providers like Google and Microsoft require these records for reliable delivery.

google.com

65/100

Security Score

Moderate email security. Several improvements are recommended to better protect your domain.

SPF (Sender Policy Framework)

SPF allows domain owners to specify which mail servers are authorized to send email on their behalf. Receiving servers check SPF to verify that incoming mail from your domain comes from an approved source.

What You'll See

The SPF record (TXT record starting with v=spf1)
Authorized mechanisms (ip4, ip6, include, a, mx)
The 'all' qualifier indicating how to handle unauthorized senders
DNS lookup count (must be 10 or fewer)

Diagnostic Value

Missing SPF record leaves your domain open to spoofing
+all (pass all) is dangerous - anyone can send as your domain
Exceeding 10 DNS lookups causes SPF to fail (permerror)
Multiple SPF records are invalid - only one allowed

The 'all' Qualifier Options

The 'all' mechanism at the end of an SPF record specifies how to handle senders not matching any previous mechanism:

-all (Fail/Hard Fail) Reject unauthorized senders. Strictest and most secure. Use when you're confident all legitimate sources are listed.
~all (SoftFail) Mark as suspicious but accept. Most common. Unauthorized mail typically goes to spam. Good for transitioning.
?all (Neutral) No assertion. Provides no protection - equivalent to no SPF. Avoid.
+all (Pass) Allow ALL senders. DANGEROUS - defeats SPF entirely. Never use.

Start with ~all, monitor with DMARC reports, then move to -all once all legitimate senders are confirmed.

History

SPF was proposed by Meng Weng Wong in 2003 and standardized in RFC 4408 (2006), later updated in RFC 7208 (2014). It was the first widely-adopted email authentication mechanism and remains fundamental to email security.

WARNING

Record

v=spf1 include:_spf.google.com ~all

DNS Lookups: 2/10

Using ~all (softfail) - consider -all for stricter enforcement

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to outgoing emails, allowing receiving servers to verify the message hasn't been altered in transit and truly originated from your domain.

What You'll See

DKIM selectors found for your domain
Public key information from DNS records
Key type (RSA or Ed25519) and size
Test mode status (t=y indicates testing, not enforced)

Diagnostic Value

Missing DKIM reduces deliverability and authentication
Keys smaller than 2048 bits are considered weak
Test mode (t=y) means signatures aren't being enforced
Empty or revoked keys (p=) indicate disabled selectors

History

DKIM evolved from DomainKeys (Yahoo, 2004) and Identified Internet Mail (Cisco). The merged standard was published as RFC 4871 in 2007, updated in RFC 6376 (2011). Unlike SPF, DKIM survives email forwarding since it signs message content.

UNKNOWN

No DKIM selectors found from common selector list

DKIM selectors vary by email provider - check your email service documentation

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together with a policy telling receiving servers what to do when authentication fails. It also enables reporting so domain owners can monitor authentication results.

What You'll See

The DMARC policy (p=none, p=quarantine, or p=reject)
Subdomain policy (sp=) if different from main domain
Percentage of messages the policy applies to (pct=)
Report URIs for aggregate (rua=) and forensic (ruf=) reports

Diagnostic Value

Missing DMARC means no policy enforcement even with SPF/DKIM
p=none only monitors - no protection against spoofing
p=quarantine sends failures to spam; p=reject blocks them
No rua= means you won't receive authentication reports

History

DMARC was developed by a consortium including Google, Microsoft, Yahoo, and PayPal, published in 2012 and standardized in RFC 7489 (2015). It was created because SPF and DKIM alone couldn't specify what action to take on failure.

PASS

Record

v=DMARC1; p=reject; rua=mailto:[email protected]

policy: reject reports enabled

{
    "domain": "google.com",
    "spf": {
        "status": "warning",
        "record": "v=spf1 include:_spf.google.com ~all",
        "mechanisms": [
            {
                "qualifier": "+",
                "mechanism": "include:_spf.google.com"
            },
            {
                "qualifier": "~",
                "mechanism": "all"
            }
        ],
        "lookups": 2,
        "issues": [],
        "warnings": [
            {
                "severity": "info",
                "message": "Using ~all (softfail) - consider -all for stricter enforcement"
            }
        ],
        "recommendations": []
    },
    "dkim": {
        "status": "unknown",
        "selectors": [],
        "issues": [],
        "warnings": [
            {
                "severity": "info",
                "message": "No DKIM selectors found from common selector list"
            }
        ],
        "recommendations": [
            "DKIM selectors vary by email provider - check your email service documentation"
        ]
    },
    "dmarc": {
        "status": "pass",
        "record": "v=DMARC1; p=reject; rua=mailto:[email protected]",
        "policy": {
            "v": "DMARC1",
            "p": "reject",
            "sp": null,
            "rua": "mailto:[email protected]",
            "ruf": null,
            "pct": 100,
            "adkim": "r",
            "aspf": "r",
            "fo": "0"
        },
        "issues": [],
        "warnings": [],
        "recommendations": []
    },
    "score": 65,
    "summary": "Moderate email security. Several improvements are recommended to better protect your domain."
}

Your IP: 216.73.216.115

About DNSApe

DNSApe is a fast, no-nonsense network diagnostics toolkit built for developers, sysadmins, and security researchers.

Version History

2.0 - 2025-12-19

Complete rewrite

Rebuilt with Laravel 12, Livewire 3, and Tailwind CSS 4
Live ping monitoring with real-time Chart.js visualization
Email Security tool: SPF, DKIM, DMARC validation
REST API with JSON responses (60 req/min)
MCP server for AI assistant integration (Claude, ChatGPT, etc.)
Slack integration with /dns, /whois, /ssl slash commands
Help tooltips explaining each tool and record type
Shareable ping sessions with unique URLs
Pretty/Raw view toggle with persistent preference
Browser-based ping for client-side latency testing
Enhanced WHOIS with domain + IP info combined
Improved SSL certificate error handling
Full-width responsive layout

Version 2.1 with performance improvements and bug fixes coming soon.

1.1.3 - 2019-04-30

Moved to new infrastructure, resolving most DNS Traversal issues
Replaced RBL with SSL validation tool

1.1.2 - 2019-04-17

Fixed DNS Traversal issue causing many requests to fail

1.1.1 - 2019-04-16

Minor UI adjustments
Added links to lookups in DNS results
Updated dependencies
Increased session timeout to 1 week to eliminate 419 errors
Updated IP address display
Removed dnsape.com as default lookup

1.1 - 2019-02-15

Several UI adjustments
Dark mode setting is persistent between sessions via cookie
Added GDPR cookie banner for session cookies
Added tool to show client IP in lookup field (settings menu)
Keyboard shortcuts for tools, focusing, text size, copying URLs
Shareable lookup URLs - browser address changes with tool usage
Added links to Github repo and feature voting
Several error handling and bug fixes

1.0.7 - 2019-01-11

Fixed HTTP Headers issue with multiple HTTPS redirects

1.0.6 - 2019-01-09

HTTP Headers now forward to and display HTTPS headers
UI adjustments

1.0.5 - 2019-01-08

Dark Mode!

1.0.4 - 2019-01-07

TLD and subdomain validation fixes

1.0.3 - 2019-01-06

Updated DNS Cache host list
IP address validation improvements
Fixed progress bar bug with failed queries
UI adjustments

1.0.2 - 2019-01-05

IPWhois and Ping now work with IP addresses as well as hostnames
Several validation enhancements reduce errors for many lookups
Several UI adjustments

1.0.1 - 2019-01-04

Added Recent Updates panel
Fixed Whois search for many TLDs
Fixed DNS Traversal for many TLDs
Changed to fluid viewport width
Added Privacy Policy

1.0 - 2019-01-02

Initial release