Email Deliverability in Runet: SPF/DKIM/DMARC 2026

Analysis via Enterno.io Email Checker for Q1 2026: 50,000 domains (.ru, .рф + RU-hosted). Checked: SPF syntax, DKIM selectors + key size, DMARC policy and tag coverage, blacklist listing (Spamhaus/Barracuda/SORBS), open-relay on 25/587.

DMARC remains the most underused — without it SPF+DKIM do not fully protect from spoofing. And p=none is "reports only", not protection.

1. SPF with +all allows sending from any server, which is equivalent to having no SPF in place. To improve security, it is recommended to use ~all or -all instead.
2. DKIM keys without rotation represent a significant risk, especially considering that only a little over half of the setups utilize keys that are 2048 bits or longer. This highlights a potential vulnerability related to private-key leaks.
3. DMARC p=none indicates a significant portion of the monitored domains, reflecting a state of monitoring without adequate protection. The objective remains to transition to p=reject for enhanced security.
4. Missing DMARC rua/ruf significantly limits the ability to track abuse effectively.
5. Open relay on 25/587 is uncommon but still found in legacy systems. The consequence of this issue can lead to blacklist listing within a short timeframe.

From a significant number of domains, a portion is listed in Spamhaus SBL/XBL, a smaller percentage in Barracuda BRBL, and an even smaller fraction in SORBS. The most common reason for these listings is compromised hosting accounts, followed by legitimate marketing emails from domains lacking proper SPF configuration.

Check a domain against blacklists online — /en/email-check.

1. Configure SPF with ~all (not +all).
2. DKIM — 2048-bit keys, rotate yearly.
3. DMARC — start with p=none + rua, then after 4 weeks → p=quarantine, another 4 weeks → p=reject.
4. Monitor blacklist status daily (Pro+ plan).
5. Follow the how-to-setup-dmarc guide.

Email deliverability in Runet 2026 is largely governed by the implementation of SPF, DKIM, and DMARC protocols, which collectively enhance the credibility of email senders and improve inbox placement rates. Properly configured, these standards can significantly improve deliverability rates, with SPF coverage at 78% and DKIM at 62%. For effective management, ensure SPF records are under 10 DNS lookups, DKIM keys are at least 2048 bits, and DMARC policies are set to 'reject' after a monitoring phase, noting that only a small percentage of DMARC implementations currently achieve this level of enforcement.

Email deliverability hinges on three critical standards: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance). These protocols work in tandem to authenticate the sender's identity and prevent email spoofing, which enhances trust with receiving mail servers.

SPF: Sender Policy Framework

SPF is a DNS record that specifies which mail servers are permitted to send email on behalf of your domain. To implement SPF, you need to create a TXT record in your DNS settings. Here’s an example:

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

This SPF record allows Google Workspace servers to send emails for your domain, while the '~all' at the end indicates a soft fail for any other servers. It’s crucial to keep the number of DNS lookups under 10 to avoid exceeding the limit set by the SPF specification.

DKIM: DomainKeys Identified Mail

DKIM adds a digital signature to your emails, allowing the recipient's server to verify that the email was indeed sent by you and hasn’t been altered in transit. To set up DKIM, generate a public/private key pair and publish the public key as a TXT record in your DNS. A typical DKIM record looks like this:

default._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB..."

Ensure your private key is securely stored on your email server. A minimum key length of 2048 bits is recommended to maximize security.

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC builds on SPF and DKIM by allowing domain owners to specify what actions should be taken when an email fails SPF or DKIM checks. A DMARC record can be created as follows:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; pct=100

In this example, the policy is set to 'reject', meaning that emails failing authentication checks will be rejected. The 'rua' and 'ruf' tags indicate where aggregate and forensic reports should be sent, providing valuable insights into your email traffic.

Practical Configuration Example

To ensure optimal email deliverability, follow these steps:

1. Create an SPF record that includes all legitimate sending sources.
2. Generate a DKIM key pair and publish the public key.
3. Implement a DMARC policy starting with 'none' for monitoring, and gradually move to 'quarantine' or 'reject' as you gain confidence in your email authentication.

For example, to check your SPF configuration, use the following command:

dig TXT yourdomain.com

This command retrieves the TXT records for your domain, allowing you to verify your SPF record.

Best Practices for Email Deliverability

• Regularly monitor your SPF, DKIM, and DMARC configurations to ensure they remain accurate.
• Use tools like MXToolbox or DMARCian to analyze your email authentication setup.
• Stay updated with changes in email authentication standards to maintain compliance.

By implementing and maintaining SPF, DKIM, and DMARC records, you can significantly enhance your email deliverability rates, ensuring that your messages reach their intended recipients in Runet 2026 and beyond.