Email Deliverability Report for infra.gov.sa

DMARC is a DNS TXT record that tells receivers what to do when a message's visible From-domain authentication does not align with SPF or DKIM. Per RFC 7489, it sits on top of SPF and DKIM as a policy and reporting layer with three policy tiers: p=none (observe), p=quarantine (route to spam), p=reject (block).

A DKIM signature is a cryptographic hash of message headers and body, signed by the sending mail server's private key. Per RFC 6376, receivers fetch the corresponding public key from DNS at <selector>._domainkey.<domain> and verify the signature — proving the message was authorized by the signing domain and was not altered in transit.

Resolve your domain's MX records, then query each MX-target IP against public DNSBL zones (Spamhaus ZEN, Barracuda, SpamCop, UCEPROTECT, Mailspike, PSBL). Use the Blacklist Lookup tool above or run a domain check from the report page. A clean result means no public listings; receiver-internal blocklists are not queryable.

The domain is not configured to receive email. Inbound mail will likely bounce or never arrive. If the domain is meant to receive mail, add MX records using the hostnames documented by your mailbox provider (Google Workspace, Microsoft 365, Zoho, Fastmail, etc.).

Your domain's current SPF record: see the SPF Checker result for parsed mechanisms, lookup count, and warnings. Validation errors typically mean syntax issues, multiple SPF records (forbidden by RFC 7208 §3.2), more than 10 DNS lookups, or unknown mechanisms — receivers treat these as permerror and skip SPF.

DMARC aggregate reports are XML files that receivers send daily to the address in your rua= tag. They show every source observed sending mail with your From-domain, what authenticated, and what failed. Forensic reports (ruf=) are per-message failure samples — most receivers no longer send these for privacy reasons. Aggregate reports require a parser; tools like Postmark, dmarcian, and EasyDMARC ingest them.

An SMTP TLS error means two mail servers could not negotiate encrypted transport. Common causes: certificate expired or mismatched, TLS version too old, cipher suite mismatch, or no STARTTLS support per RFC 3207. Modern best practice is TLS 1.2 minimum, ideally TLS 1.3.

MTA-STS is a DNS- and HTTPS-published policy that lets domain owners require TLS encryption for inbound SMTP connections from compliant senders. Per RFC 8461, it has three modes: enforce (strict TLS required), testing (observation), none (opt-out). Combined with TLS-RPT, it prevents downgrade attacks on inbound mail.

Common causes: (1) the IP sent spam (compromised account, misconfigured forwarder, real abuse); (2) the IP is shared with other senders behaving badly (cloud-provider ranges); (3) the IP was previously used by a spammer (carry-forward listing); (4) excessive bounce or complaint rates triggered automatic listing. Identify the listing reason on the operator's site and submit a delisting request after fixing the root cause.

No. Gmail's Promotions tab is a category for marketing mail; messages there are still delivered to the inbox view, just sorted into a tab. Spam is a separate filter that keeps mail out of all inbox tabs. DMARC and DNS authentication do not control tab placement; that is decided by Gmail's content classifier based on signals like sender history and message structure.

Yes. New or low-volume domains have no sending reputation, and receivers like Gmail and Outlook treat unfamiliar senders cautiously by default. Authentication that passes is necessary but not sufficient — building reputation requires consistent volume, low complaint rates, and engagement over weeks. Warmup tools and sending platforms with established reputation can help.

Yes, if your domain is meant to receive email. Without an MX record, receivers fall back to the A record per RFC 5321 §5.1, but this fallback is rarely reliable — most mail will bounce. Domains used only for outbound sending technically do not require an MX record, but publishing one is recommended for clarity.

An A record maps a hostname to an IPv4 address (used for web traffic, SSH, etc.). An MX record maps a domain to one or more mail-server hostnames, ranked by priority. MX records do not contain IPs directly; they point at hostnames whose A or AAAA records resolve. Per RFC 5321, mail servers consult MX first, then resolve the target hostname to an IP.

For a domain to receive mail, yes. Without an MX record, most receivers will bounce inbound mail rather than fall back to the A record. For a send-only domain (no inbound mail), MX is technically optional, but publishing one (often pointed at your mail provider) is recommended for diagnostic clarity.

permerror means the receiver could not evaluate SPF because the record is broken — typically duplicate SPF records, syntax errors, or more than 10 DNS lookups per RFC 7208 §4.6.4. Audit the TXT records, merge duplicates into one, and reduce include: chains until lookups are 10 or fewer.

550 5.7.1 with SPF reason is a hard rejection from a receiver enforcing SPF — usually because your sending IP is not authorized by the published SPF record. Either add the IP to your SPF (via ip4: or the provider's include: directive) or relay through an authorized sender.

Run the SPF Checker against your domain. The result shows the parsed record, lookup count, and any flagged warnings. Common fixes: merge multiple SPF records into one, replace +all with ~all or -all, prune include: chains to stay under 10 lookups, remove deprecated ptr mechanisms.

DNS publication is immediate (within the TTL — usually minutes to hours). Aggregate reports start arriving the next day from receivers that send rua reports. To safely promote from p=none → p=quarantine → p=reject, plan ~30 days at each tier to verify legitimate sources continue passing.

Gmail's bulk-sender requirements (effective February 2024) require senders of more than 5,000 messages per day to Gmail addresses to publish a DMARC record. Yahoo and Microsoft published parallel requirements. Below 5,000/day, DMARC is strongly recommended but not strictly enforced.

Start with v=DMARC1; p=none; rua=mailto:reports@<your-domain>; to gather data. Once aggregate reports confirm all legitimate sources pass for 30+ days, move to p=quarantine; pct=10; to ramp gradually, then increase pct to 100 over 2-4 weeks. Promote to p=reject once quarantine has run cleanly. Use aspf=r adkim=r (relaxed alignment, the defaults) unless you have a specific reason to require strict.

Receivers cannot verify your domain authorized the message and cannot detect content tampering. Per the 2024 Gmail/Yahoo bulk-sender requirements, senders of more than 5,000 messages per day to those providers must have DKIM. Mail without DKIM is more likely to be filtered to spam or rejected.

Yes — they cover different parts of the message path. SPF authorizes which servers may send mail using your domain envelope. DKIM signs the message body and headers cryptographically. DMARC requires either SPF or DKIM to align with the visible From-domain; modern best practice is to ship both so DMARC has two paths to pass.

Yes. Every modern mailbox provider — Google, Microsoft, Yahoo, Apple — uses DKIM as a primary trust signal. Most providers (Google Workspace, Microsoft 365, Resend, Postmark, etc.) make enabling DKIM a one-click operation. The only valid reason to skip DKIM is if you do not control the sending infrastructure, in which case ask your provider.

Yes — listings happen automatically based on observed traffic. You will not receive notification from most blocklist operators. The first sign is usually a spike in mail-rejection bounces or customer reports of missing email. Periodic blocklist checks are part of routine email-infrastructure hygiene.

Varies by operator. Spamhaus and SpamCop typically remove within 24-72 hours of a documented self-removal request, provided the cause is fixed. Some operators auto-expire listings after a fixed period (often 7-14 days) if no further bad traffic is observed. UCEPROTECT range-based listings (L2/L3) usually require contacting the IP-range owner, not just yourself.

Identify which blocklist is causing the rejection (the receiver's bounce message usually names the blocklist or includes the URL). Visit that blocklist's lookup tool, find your IP, follow the documented self-removal flow (often a form requiring you to confirm the cause is fixed). For range-based listings, contact your IP provider — you cannot delist a range you do not own.

MTA-STS (RFC 8461) is a policy — it tells compliant senders 'use TLS or refuse to deliver to me.' TLS-RPT (RFC 8460) is a reporting endpoint — receivers send you daily JSON reports of TLS-delivery successes and failures. They complement each other: MTA-STS prevents fallback to plaintext; TLS-RPT tells you whether anyone is hitting that fallback path.

Yes, for any domain with significant inbound mail. MTA-STS in enforce mode prevents downgrade attacks (a man-in-the-middle stripping the STARTTLS upgrade). The cost is small — a DNS TXT record, a tiny HTTPS endpoint at mta-sts.<domain>, and the discipline to keep certificate + MX records in sync with the policy.

Run the TLS Check tool. The MTA-STS section shows the published mode (enforce / testing / none / not-published) and any policy parsing errors. If the section says not-published, no MTA-STS DNS hint exists at the apex. Only enforce provides actual TLS enforcement; testing is observation-only.

Yes — strict policies can reject legitimate-but-misaligned mail. Common cases: third-party senders (Mailchimp, SendGrid, etc.) that sign DKIM with their own domain rather than yours; SPF that does not authorize the third-party's sending IPs; relaxed-vs-strict alignment mismatches. Always ramp DMARC via p=none → p=quarantine → p=reject over 30+ days each, watching aggregate reports for legitimate sources failing.

Common causes: (1) the sending server is not signing messages at all; (2) the wrong selector is published in DNS; (3) the public key in DNS does not match the private key in use; (4) the message was modified by a forwarding hop after signing; (5) the public key has been revoked (p= empty per RFC 6376 §3.6.1). Inspect the failed message's Authentication-Results header to see which class.

Yes. DKIM can sign with a domain different from the visible From-domain — common with third-party senders. DMARC requires alignment between the DKIM signing domain and the From-domain. DKIM passing on a non-aligned domain leaves DMARC to fall back to SPF; if SPF also does not align, DMARC fails even though both protocols are technically passing.

Yes. Public blocklists (Spamhaus, Barracuda, etc.) are one signal among many. Gmail also weighs its own internal reputation systems, recipient engagement (open rate, complaint rate, reply rate), content scoring, and sender history. A clean public-blocklist record is necessary but not sufficient for inbox placement.

STARTTLS is an SMTP command that upgrades a plaintext SMTP session to encrypted transport. Per RFC 3207, the receiving server advertises STARTTLS in its EHLO response; the sending server issues STARTTLS, both sides negotiate TLS, then continue the SMTP session encrypted. Modern best practice is TLS 1.2 minimum, ideally TLS 1.3.

Before promoting to p=reject, run p=quarantine for 30+ days and confirm aggregate reports show no legitimate sources failing. Inventory every system that sends mail with your domain: ESPs, transactional providers, internal apps, helpdesk tools, calendar invites, billing systems. Each must align via SPF or DKIM. If a single legitimate source fails, p=reject will block real mail.

Run the SPF Checker to see your domain's current SPF state. RFC 7208 §3.2 requires exactly one SPF record per domain. Multiple v=spf1 TXT records cause permerror and SPF is ignored entirely. Merge all authorized senders into a single record.

RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups (each include:, mx, a, redirect=, or exists: counts as one). Records that exceed this trigger permerror regardless of sender legitimacy. Compound include: chains are the usual culprit; use SPF flattening or prune obsolete includes.

Mailbox providers weigh sending patterns alongside authentication. A sudden volume increase from a previously low-volume sender looks suspicious — providers throttle, flag for review, or filter to spam. Established senders ramp gradually; warming a new IP or new domain by sending at controlled volumes over 2-4 weeks is standard practice.

Deliverability is the product of many independent systems: DNS configuration, SPF/DKIM/DMARC alignment, sender reputation across multiple receivers, content scoring, recipient engagement, IP reputation, and provider-internal anti-abuse rules. Most of these are unobservable from outside the receiver. Authentication (which Relaymetry checks) is the controllable foundation; reputation and engagement build over time.

Domain health is the combined state of how your domain authenticates outbound mail and what receivers can verify about you from public DNS records. It includes MX, SPF, DKIM, DMARC, blocklist presence, and TLS posture. Each is one signal of readiness; none alone determines deliverability. Run a check from the home page to see all six on one report.

The best DMARC checker is one that is instant, free, and shows the actual record + alignment + policy in plain English without an account or upsell. Relaymetry's DMARC Checker does that. For aggregate-report parsing (Phase 2 product capability), look at Postmark, dmarcian, or EasyDMARC. For one-shot record inspection, any modern tool works — pick the one with the cleanest UX for your team.