{"id":18232,"date":"2026-03-09T11:52:19","date_gmt":"2026-03-09T10:52:19","guid":{"rendered":"https:\/\/webhosting.de\/spf-dkim-dmarc-hosting-email-sicherheit-serverauth-server\/"},"modified":"2026-03-09T11:52:19","modified_gmt":"2026-03-09T10:52:19","slug":"spf-dkim-dmarc-hosting-email-security-serverauth-server","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-hosting-email-sicherheit-serverauth-server\/","title":{"rendered":"SPF DKIM DMARC Hosting: Set up e-mail authentication optimally"},"content":{"rendered":"<p>I set up email authentication in hosting in such a way that deliverability and protection increase measurably - with a focus on <strong>spf dkim dmarc hosting<\/strong> and clean DNS policies. I guide you step by step through records, alignment and reporting so that legitimate senders are clearly recognizable and attackers are kept out.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>SPF policy<\/strong> limits permitted dispatch servers and stops spoofing.<\/li>\n  <li><strong>DKIM signature<\/strong> secures content and sender integrity.<\/li>\n  <li><strong>DMARC alignment<\/strong> combines policy, protection and reports.<\/li>\n  <li><strong>DNS quality<\/strong> with short TTLs facilitates changes.<\/li>\n  <li><strong>Reporting<\/strong> uncovers misuse and misconfigurations.<\/li>\n<\/ul>\n\n<h2>Why SPF, DKIM and DMARC are mandatory in hosting<\/h2>\n\n<p>Phishing dominates attacks on mail environments, which is why I rely on clear <strong>Authentication<\/strong> instead of hope. Without SPF, DKIM and DMARC, everyone uses your domain as a sender, which leads to spam, data theft and a damaged reputation. Large mailboxes severely evaluate missing or incorrect policies, which is why I immediately provide every new domain with basic protection. A clean setup increases the chance of inboxes and significantly reduces bounces. DMARC reports also provide objective signals as to whether the <strong>Alignment<\/strong> or fraudsters try to misuse your sender address.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/email-authentifizierung-server-7082.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Understanding SPF and setting it correctly<\/h2>\n\n<p>SPF determines which hosts are allowed to send mail for your domain, and I keep the record as lean as possible for better <strong>Performance<\/strong>. Typical elements are ip4\/ip6, include, a, mx and a final all with soft or hard fail. For productive domains I usually use \u201c-all\u201d if all legitimate paths are covered; in introductory phases I start with \u201c~all\u201d so as not to exclude any legitimate shipping. Redirects can break SPF, which is why I always combine SPF with DKIM so that the check does not fail in the case of forwarders. For transparency, I document every integrated third-party provider in the internal change log so that nobody forgets to check the <strong>Record<\/strong> for new tools.<\/p>\n\n<p>If you would like to read up on the context in a compact form, you will find in this <a href=\"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-bimi-explains-optimal-email-security-matrix\/\">Security matrix<\/a> a structured classification of the protocols and their tasks.<\/p>\n\n<h2>SPF units for complex setups<\/h2>\n\n<p>In larger environments, I only use \u201credirect=\u201d if a central policy is really to be inherited; otherwise I stick with \u201cinclude=\u201d to remain flexible per domain. I leave out the often seen \u201cptr\u201d - the mechanism is imprecise and is no longer recommended by filters. I use \u201cexists\u201d sparingly because complex DNS responses can generate unnecessary lookups. For hosts that never send mails, I publish a separate SPF on the HELO\/EHLO name (e.g. mailhost.example.tld with \u201cv=spf1 -all\u201d) so that recipients can also reliably check the HELO identity. I only use \u201cflattening\u201d (resolving includes in IPs) in a controlled manner, as provider IPs change and then authentication breaks unnoticed; I therefore plan regular revalidations. For dispatch infrastructures with IPv6, I explicitly note ip6 networks and keep backward resolutions (PTR) and HELO names consistent to avoid negative heuristics.<\/p>\n\n<h2>DKIM: Signatures, selector and key maintenance<\/h2>\n\n<p>DKIM signs outgoing messages cryptographically, allowing recipients to recognize changes to the content immediately and ensuring reliable <strong>Identity<\/strong> check. I use 2048-bit keys and separate different dispatch channels as required with individual selectors, such as \u201cmarketing\u201d and \u201cservice\u201d. This allows each system to be isolated quickly if a signature fails or a key needs to be renewed. For gateways that handle mails, I activate header canonicalization relaxed\/relaxed so that small changes do not invalidate the signature. Regular key rotation reduces the risk of misuse and keeps the <strong>Reputation<\/strong> clean.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/EmailAuthMeetingSetup_7634.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>DKIM in practice: fields, hashes and rotation<\/h2>\n\n<p>For robust signatures, I choose hash \u201csha256\u201d and sign at least From, Date, To, Subject and Message-ID; where possible, I also \u201coversign\u201d sensitive headers so that subsequent changes are noticeable. I split long public keys correctly into 255-character segments in the TXT record to avoid truncation errors. I take a two-stage approach to rotation: roll out a new selector, convert active systems and remove the old selector after a defined grace period. In this way, deliveries remain stable even if individual gateways are updated late. Ed25519 is not yet accepted everywhere in practice; I remain compatible with RSA 2048. For gateways that change bodies (e.g. disclaimers), I avoid the optional DKIM \u201cl=\u201d (body length) - it increases complexity and makes analyses more difficult.<\/p>\n\n<h2>DMARC: Policy, Alignment and Reports<\/h2>\n\n<p>DMARC links SPF and DKIM with a clear <strong>Policy<\/strong> and checks whether the visible from-domain matches at least one check signal. I start with \u201cp=none\u201d and activate aggregate reports (rua) so that I can see who is sending on behalf of the domain. As soon as all legitimate sources report cleanly, I switch to \u201cquarantine\u201d and later to \u201creject\u201d. This step-by-step model reduces risks for legitimate mail flows and gradually increases protection. I also pay attention to alignment modes (relaxed\/strict) so that the <strong>Domains<\/strong> work consistently, even if subdomains are involved.<\/p>\n\n<h2>DMARC in detail: tags, subdomains and step-by-step enforcement<\/h2>\n\n<p>In addition to p, rua, adkim and aspf, I use \u201csp=\u201d specifically for subdomains: If the main domain is sending productively but subdomains are not, I set \u201csp=reject\u201d to close unused spaces. With \u201cpct=\u201d I can roll out enforcement proportionally (e.g. 50 %) before I go to 100 %. \u201cri=\u201d controls the reporting frequency, most receivers deliver on a daily basis anyway. I evaluate forensic reports (ruf\/fo) with a view to data protection and limited support; in practice, aggregate reports provide the relevant patterns. For clean alignment, I make sure that the envelope sender (return path) matches the domain family or that DKIM consistently signs the visible from-domain. In mixed environments with several tools, I initially set aspf\/adkim to relaxed, then tighten to strict as soon as all paths run consistently under a domain family.<\/p>\n\n<h2>DNS records: Syntax, TTL and examples<\/h2>\n\n<p>DNS publication determines the speed and reliability of <strong>Changes<\/strong>. For SPF, I use \u201cv=spf1 include:... -all\u201d and pay attention to the 10-lookup limit by deleting superfluous includes or noting IP blocks directly. I publish DKIM records under selector._domainkey.example.tld as TXT with \u201cv=DKIM1; k=rsa; p=...\u201d. DMARC is under _dmarc.example.tld as \u201cv=DMARC1; p=none; rua=mailto:...; adkim=r; aspf=r\u201d. Low TTLs like 300-900 seconds help with testing, then I increase the TTL for less <strong>Traffic<\/strong> and more stable caches.<\/p>\n\n<h2>DNS governance and security<\/h2>\n\n<p>In productive zones, I maintain consistent TTL profiles: short for movable entries (SPF, DKIM selector), longer for stable ones (NS, SOA). I always publish DKIM keys as TXT; I only set CNAME redirects to provider hosts if the platform explicitly provides for this. I check whether TXT values are correctly segmented in quotation marks so that name servers do not insert any silent breaks. I use DNSSEC to secure the zone against manipulation - this is particularly useful if several teams or providers make changes. In multi-DNS setups, I anchor ownership per record (runbook) so that no configuration battles arise and roles remain cleanly separated.<\/p>\n\n<h2>Check deliverability and rectify errors quickly<\/h2>\n\n<p>After each change, I test SPF, DKIM and DMARC with independent mailboxes and header analyses for maximum <strong>Transparency<\/strong>. I quickly recognize typical errors: incorrect selector names, truncated DKIM keys, SPF lookup limit or a missing \u201c-all\u201d. Empty reports often indicate typos in rua addresses, which I correct immediately. If legitimate sources appear with fail, I check whether another gateway is forwarding mails and thus destroying SPF; DKIM should then still exist. For critical dispatch paths, I maintain a controlled rollback plan so that the <strong>Inbox<\/strong> does not suffer.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/email-authentication-hosting-setup-7894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Forwarding, mailing lists and ARC<\/h2>\n\n<p>Forwarders and mailing lists often change envelope senders, headers or the body. SPF then regularly fails because the forwarding host is not in your policy. I mitigate this with consistent DKIM signatures and recommend SRS for forwarders so that SPF survives. Mailing lists typically add prefixes in the subject or customize footers - ARC (Authenticated Received Chain) helps here because it documents the chain of trust. Where gateways support ARC, I activate verification so that legitimate but modified messages are not unnecessarily devalued. If you work intensively with lists, start with relaxed alignment for DMARC and only apply the policy once all paths have been verified.<\/p>\n\n<h2>Comparison and application scenarios<\/h2>\n\n<p>For everyday life, I rely on the interaction of all three <strong>Protocols<\/strong>, because each component addresses a different type of deception. SPF identifies the sending host, DKIM secures the message, DMARC provides control and visibility. If one fails at short notice, the other continues to carry the authentication, which keeps the delivery stable. I therefore plan redundancy: several dispatch paths with a valid DKIM signature and SPF with a clear policy. The following table briefly summarizes functions and typical deployment ideas so that you can quickly find the right <strong>Strategy<\/strong> choose.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Protocol<\/th>\n      <th>Purpose<\/th>\n      <th>Strengths<\/th>\n      <th>Boundaries<\/th>\n      <th>DNS example<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>SPF<\/strong><\/td>\n      <td>Define permitted shipping sources<\/td>\n      <td>Clear host verification; simple maintenance<\/td>\n      <td>Breaks on forwarding; 10-lookup limit<\/td>\n      <td>v=spf1 include:_spf.example.com -all<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>DKIM<\/strong><\/td>\n      <td>Content and sender integrity<\/td>\n      <td>Forwarding uncritical; selectable<\/td>\n      <td>Changes through gateways jeopardize signature<\/td>\n      <td>v=DKIM1; k=rsa; p=BASE64KEY<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>DMARC<\/strong><\/td>\n      <td>Policy, Alignment, Reporting<\/td>\n      <td>Controls receiver response; visibility<\/td>\n      <td>Requires functioning SPF\/DKIM<\/td>\n      <td>v=DMARC1; p=quarantine; rua=mailto:rua@tld<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Roles, sender domains and return path design<\/h2>\n\n<p>I separate transactional and marketing emails on subdomains (e.g. mail.example.tld vs. news.example.tld). This keeps reputation and analyses clean and I can apply differentiated policies. The return path (envelope sender) points to a separate, controlled domain that fulfills SPF and reliably processes bounces. If the visible from domain (5322.From), DKIM-d= and envelope domain match on the family side, DMARC alignment is stable - especially with third-party providers. I avoid \u201cNo-Reply\u201d because a lack of response capability can attract negative attention from filters and make support flows more difficult. Instead, I route replies in a controlled manner to dedicated mailboxes with clear roles.<\/p>\n\n<h2>Hosting panels and workflows: Plesk, cPanel, Cloud<\/h2>\n\n<p>In Plesk and cPanel, I activate DKIM directly in the panel, load my own keys if necessary and check the <strong>Selector<\/strong> in the DNS. Many cloud mailers publish ready-made records; I transfer them exactly and test with short TTLs. For multiple sender domains, I separate sending channels per selector so that analyses remain clear and the rotation runs in an orderly fashion. I also keep a checklist ready for each panel, in which all the necessary steps are listed in the correct order. Anyone using Plesk will find useful steps for fine-tuning in this compact guide: <a href=\"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-plesk-guide-safety-tuning-professional\/\">Plesk-Guide<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/email_authentication_techoffice_1943.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automation and versioning<\/h2>\n\n<p>For repeatable quality, I use templating for SPF, DKIM selectors and DMARC. I document DNS changes in a versioned form, including ticket, date, reason and rollback path. Before going live, I run a staging zone with short TTLs and validate syntax (e.g. double semicolons, missing quotes) automatically. I plan change windows and then actively monitor the authentication results in incoming confirmation emails so that any deviations are noticed immediately. If third-party providers are integrated or changed, I trigger this in a standardized way: SPF update, create DKIM selector, test mails, DMARC monitoring, release - always in the same order.<\/p>\n\n<h2>Read and act on DMARC reports<\/h2>\n\n<p>Aggregate reports show which hosts are broadcasting on behalf of your domain, and I analyze them daily to <strong>Abuse<\/strong> to stop them. If unknown IPs appear, I block them in firewalls or remove faulty includes from the SPF record. If alignment fails regularly, I adjust sender addresses or return paths until DMARC gives the green light. For structured analyses, I filter reports by source, result and volume so that real risks land first. This article provides a practical introduction to the analysis: <a href=\"https:\/\/webhosting.de\/en\/dmarc-reports-spoofing-analyze-securenet\/\">Evaluate DMARC reports<\/a>.<\/p>\n\n<h2>Evaluate report data efficiently<\/h2>\n\n<p>DMARC aggregates come compressed (zip\/gzip) in XML format. I first check the top senders, their pass\/fail ratio and whether SPF or DKIM provides the alignment. I park regular outliers with low volume until patterns emerge; I prioritize large volumes with fail. I use multiple recipient addresses in the rua tag to supply teams (e.g. Operations and Security) in parallel and normalize the data by provider to quickly assign misconfigurations. Noticeable peaks often indicate campaign launches, new tools or misuse - I immediately take countermeasures (SPF cleanup, selector fix, policy tightening).<\/p>\n\n<h2>More security around mail<\/h2>\n\n<p>Email authentication works even better when I use logins with MFA, long passphrases and graded <strong>Rate limits<\/strong> protect. In addition, I only enable SMTP auth where it is needed and enforce TLS on all transport routes. Role mailboxes are not given admin rights in order to limit lateral movement. Raising awareness in the team prevents clicks on dangerous content and noticeably reduces the attack surface. In addition, I monitor unusual mail volumes so that compromises do not go undetected and the <strong>Reputation<\/strong> holds.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/email_auth_setup_desk_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BIMI and brand protection<\/h2>\n\n<p>If you want to display your logo in supported mailboxes, prepare BIMI. The prerequisite is an enforced DMARC policy (quarantine or reject) with stable alignment. I store a clean SVG logo and ensure consistent sender domains across all systems. Depending on the mailbox provider, verified brand verification (VMC) may be required. BIMI does not directly improve delivery, but increases trust, recognition and willingness to click - and at the same time makes manipulation more obvious. I only plan to introduce BIMI once SPF, DKIM and DMARC have been running smoothly for weeks and reports no longer show any anomalies.<\/p>\n\n<h2>Frequent errors and quick checks<\/h2>\n\n<p>Many SPF records burst because of too many includes, so I consolidate entries and rely on direct <strong>IP blocks<\/strong>, where appropriate. DKIM errors are often caused by incorrect breaks in the TXT record; I check the length and remove superfluous quotation marks. I immediately recognize DMARC entries with double semicolons or incorrect keys such as \u201cruf\u201d instead of \u201crua\u201d in syntax tests. Another classic is missing PTR entries or inappropriate HELO names that trigger spam filters; here I make sure that the host names are unique. Finally, I check that each subdomain that sends mails fulfills its own alignment, otherwise the <strong>Policy<\/strong> from.<\/p>\n\n<h2>From p=none to p=reject: Roadmap in 30 days<\/h2>\n\n<p>On day 1, I set DMARC to \u201cp=none\u201d and collect reliable data. <strong>Data<\/strong>. Up to day 10, I verify all legitimate sources, rotate missing DKIM keys and clean up SPF lookups. Between day 11 and 20, I switch to \u201cquarantine\u201d and observe the effects on deliverability in real time. If legitimate emails reach the inbox in a stable manner, I switch to \u201creject\u201d by day 30 and continue to keep an eye on the reports. This process minimizes the risk of failure and leads to consistent and controlled <strong>Protection<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/emailauthentifizierung-5501.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>To take away<\/h2>\n\n<p>With clean <strong>spf dkim dmarc hosting<\/strong> I secure the sender, content and delivery measurably: SPF regulates sources, DKIM secures messages, DMARC controls the recipient's reaction. If you take a step-by-step approach, use short TTLs, read reports and constantly adjust them, you will achieve a reliable inbox quota without any nasty surprises. Check, measure, tighten - this is how I establish reliable authentication and keep the domain trustworthy in the long term.<\/p>","protected":false},"excerpt":{"rendered":"<p>Make the most of **spf dkim dmarc hosting**: Guide to email authentication, SPF, DKIM, DMARC for maximum mail security and deliverability.<\/p>","protected":false},"author":1,"featured_media":18225,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[791],"tags":[],"class_list":["post-18232","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-emailserver-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1111","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"spf dkim dmarc hosting","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18225","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/18232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=18232"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/18232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/18225"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=18232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=18232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=18232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}