The rDNS configuration that lets Gmail and Microsoft accept your connection in the first place.
PTR records, forward-confirmed reverse DNS, HELO alignment, RIR sub-delegation for your own blocks.

A one-time engagement configuring reverse DNS for all sending IPs assigned to your operation with full alignment across the related identifiers that ISP filters check. The deliverables: PTR record per IP pointing to a hostname matching your sending domain pattern (mail-01.yourdomain.com rather than generic provider hostnames); forward A record on the PTR hostname pointing back to the IP to satisfy forward-confirmed reverse DNS (FCrDNS); HELO/EHLO banner configuration on the sending MTA aligned with the PTR hostname; verification across major mailbox providers (Gmail, Microsoft 365, Yahoo, ProtonMail) that the configuration passes their rDNS checks; IPv6 ip6.arpa coverage if dual-stack sending; optional RIR sub-delegation for customers with /29 or larger blocks who want to manage their own reverse zone; documentation of the per-IP configuration for inclusion in your sender authentication evidence. One-time engagement EUR 199, delivery in 5 business days.

Because Gmail and Microsoft 365 reject or defer mail from IPs without valid PTR records and reduce trust for IPs whose PTR does not align with the claimed sender identity. Google formalised this requirement in February 2024 as part of their sender guidelines update; the policy applied to all senders sending more than 5,000 messages per day to personal Gmail accounts, but in practice Gmail filters apply rDNS checks to all incoming connections. Microsoft 365 has similar policies through Exchange Online Protection and has explicit rejection patterns when the PTR hostname does not match the IP. Yahoo and ProtonMail apply similar but less strictly documented rules. The practical effect: an IP without rDNS sees connection rejections with codes like "550 IP not in DNS" or "host name does not match IP address"; an IP with generic provider rDNS (192-168-1-1.provider.net pattern) sees increased spam scoring; an IP with FCrDNS-aligned rDNS gets past the baseline trust check and lets SPF, DKIM, and DMARC do the rest of the authentication work. Without rDNS, the other authentication signals matter less because the connection itself raises trust concerns.

Forward-Confirmed Reverse DNS. The mechanism: when a receiving mail server gets an SMTP connection from your IP, it does a PTR lookup on your IP to find the hostname (the PTR record), then does an A lookup on that hostname to confirm it resolves back to the same IP. If both lookups match, FCrDNS is satisfied. If the PTR record points to mail-01.yourdomain.com but mail-01.yourdomain.com does not have an A record back to your IP, FCrDNS fails. FCrDNS is not an RFC-mandated requirement (RFC 5321 mentions rDNS but does not require FCrDNS), but Gmail and Microsoft use it as a trust signal. A failed FCrDNS does not necessarily mean rejection but it raises your spam score and reduces tolerance for any other authentication issues. The engagement deploys both halves: PTR record on the IP and corresponding A record on the hostname, verified through dig from external resolvers before signoff.

PTR records are controlled by the owner of the IP address block, not by your domain registrar. For IPs assigned to your operation by ASH, we are the IP block owner and can set PTR records directly through our infrastructure management. For dedicated IPs that ASH allocates to your operation, the PTR records get configured during this engagement without requiring external coordination. For customers who bring their own IP blocks (BYOIP, typically /29 or larger allocations that customers obtained directly from a RIR), the engagement coordinates with the RIR (ARIN, RIPE, APNIC, AFRINIC, LACNIC depending on region) to configure sub-delegation of the reverse zone to ASH nameservers, after which we manage the PTR records as usual. For IPs that customers obtained from third-party hosting providers and route through ASH infrastructure (less common), the engagement documents what PTR configuration is needed and the customer requests it from their IP owner; we cannot configure PTR records for IPs we do not control or have not received reverse delegation for.

The HELO/EHLO SMTP command is how the sending MTA identifies itself to the receiving server at the start of the SMTP conversation. The hostname declared in HELO/EHLO should match the PTR record for the IP making the connection. If your IP 203.0.113.50 has PTR mail-01.yourdomain.com but your MTA HELO declares "smtp.yourdomain.com", the mismatch raises trust concerns even though both hostnames may be under your domain. Gmail and Microsoft check the HELO/EHLO value against the PTR record and add spam score for mismatches. The engagement configures the sending MTA (PowerMTA, Postfix, exim, depending on your stack) to declare HELO/EHLO matching the PTR hostname for each sending IP. For multi-IP configurations, this means per-IP HELO/EHLO configuration rather than a single hostname for all IPs. PowerMTA supports this through the virtual-mta and ip-address configuration; Postfix supports this through smtp_helo_name with multiple-instance configuration or transport_maps.

IPv6 PTR records live in the ip6.arpa zone with the IPv6 address expressed in reverse nibble notation. The mechanics are the same as IPv4 (PTR record per IP, FCrDNS verification, HELO/EHLO alignment) but two operational complications matter. First: many ISPs and hosting providers do not delegate IPv6 reverse zones to customers, which means you cannot manage your own IPv6 PTR records even if you would like to. ASH controls our own IPv6 allocations and can configure PTR records for IPv6 sending IPs we provide. Second: the verbose notation of IPv6 PTR records (each hex nibble reversed, separated by dots, ending in ip6.arpa) makes manual configuration error-prone. We use templated configuration that generates PTR records from IPv6 addresses automatically. For dual-stack operations sending from both IPv4 and IPv6, both PTR records get configured during the engagement. For operations sending IPv4-only with IPv6 disabled at the MTA, IPv6 PTR is not needed.

For customers with their own IP allocations of /29 or larger (32 or more IPv4 addresses, RIPE policy minimum for delegation), the RIR can delegate the reverse zone to nameservers of the customer's choice. The customer then manages PTR records on their own nameservers rather than going through the IP block owner. Process: customer logs into their RIR account (ARIN, RIPE, APNIC) and adds the ASH nameservers to the reverse zone delegation; ASH adds the reverse zone to our DNS infrastructure; PTR records get managed by the customer through us. For /24 and larger allocations, delegation is straightforward and standard. For /25 through /29 allocations, classless reverse delegation (RFC 2317) applies, which requires the IP block owner to publish CNAME records in the parent zone pointing to the customer-managed sub-zone. ASH supports both standard and classless delegation; the engagement scopes which applies based on your block size and configures appropriately.

Three verification commands cover the baseline. First: dig -x YOUR_IP +short returns the PTR record value (should be your declared sending hostname). Second: dig PTR_HOSTNAME +short returns the A record value (should match YOUR_IP, confirming FCrDNS). Third: send a test message to check-auth@verifier.port25.com or use Mail Tester from your sending IP; the response includes a section on rDNS configuration with explicit pass/fail flags. The engagement runs all three verifications across every sending IP before signoff. The verification report documents per-IP rDNS status, FCrDNS confirmation, HELO/EHLO alignment, and any IPs where downstream mailbox providers flag issues (rare after correct configuration, but possible for IPs with prior reputation history). The verification report is delivered with the engagement; customers can re-run the same commands independently any time to confirm configuration remains in place.