{"id":19561,"date":"2026-05-31T18:18:04","date_gmt":"2026-05-31T16:18:04","guid":{"rendered":"https:\/\/webhosting.de\/dkim-canonicalization-signaturstabilitaet-mailserver-absicherung\/"},"modified":"2026-05-31T18:18:04","modified_gmt":"2026-05-31T16:18:04","slug":"dkim-canonicalization-signature-stability-mail-server-security","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/dkim-canonicalization-signaturstabilitaet-mailserver-absicherung\/","title":{"rendered":"DKIM canonicalization and signature stability for secure mail servers"},"content":{"rendered":"<p>I will explain in two sentences how <strong>DKIM Canonicalization<\/strong> Header and body standardized so that the signature remains valid despite minor transport changes. This is how I keep the <strong>Signature<\/strong> reliably on real mail channels and achieve a high delivery rate without jeopardizing the cryptographic check.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>So that you can get started right away, I will summarize the key aspects of the <strong>Canonicalization<\/strong> and signature stability.<\/p>\n<ul>\n  <li><strong>relaxed<\/strong> equalizes format details and increases the chance of a valid check.<\/li>\n  <li><strong>simple<\/strong> is strict and breaks faster with the smallest changes.<\/li>\n  <li><strong>Header<\/strong> should usually be treated in a relaxed manner, body also relaxed.<\/li>\n  <li><strong>Forwarding<\/strong>, gateways and auto-responders ripple formatting.<\/li>\n  <li><strong>DMARC<\/strong> benefits from consistent DKIM checks if SPF fails.<\/li>\n<\/ul>\n<p>I implement these points consistently because small format changes occur frequently and the <strong>Validity<\/strong> of the signature. For mailing lists and gateways in particular, the right choice of <strong>Modes<\/strong> via delivery or spam folder. Relaxed handling of spaces and line breaks ensures more successful checks of the <strong>Signature<\/strong>. At the same time, I keep an eye on relevant headers so that there is no scope for manipulation. In this way, I achieve a good balance between <strong>Security<\/strong> and suitability for everyday use.<\/p>\n\n<h2>What does DKIM Canonicalization mean?<\/h2>\n\n<p>Canonicalization refers to the rules I use to bring the header and body into a uniform form before the signature, so that the <strong>Examination<\/strong> sees the same byte sequence on the target server. Emails change easily en route: gateways insert headers, archive systems touch line breaks, scanners adjust encoding - and this is precisely where <strong>relaxed<\/strong>. The simple mode tolerates hardly any deviations, while relaxed standardizes spaces and breaks so that the <strong>Signature<\/strong> remains valid despite cosmetic changes. In the DKIM signature, I define the modes as c=header\/body, for example c=relaxed\/relaxed or c=simple\/relaxed for header and <strong>Body<\/strong>. I prefer relaxed\/relaxed because typical format corrections along the transport chain do not generate false alarms. This means that the cryptographic significance of the <strong>DKIM<\/strong>-signature, while unnecessary rejections happen less often.<\/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\/05\/sichere-mailserver-dkim-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Why canonicalization is crucial for signature durability<\/h2>\n\n<p>I aim for maximum consistency of the <strong>Signature<\/strong>, because any valid check builds trust with the recipient. Forwarding via mailing lists puts prefixes in the subject or adds footers, and too strict a <strong>Configuration<\/strong> then breaks quickly. Security gateways partially rewrite headers and bodies, which cushions relaxed better and therefore produces fewer invalid signatures. Archive systems or auto-responders change metadata, which is why I consciously select the signed headers and use relaxed. The more often DKIM remains valid, the clearer the evaluation of my <strong>Domain<\/strong> and the fewer legitimate messages end up in spam. This protects brand reputation and keeps communication channels free of disruptions.<\/p>\n\n<h2>How relaxed and simple work in detail<\/h2>\n\n<p>To ensure that my decisions are reproducible, I observe the specific rules of canonicalization:<\/p>\n<ul>\n  <li><strong>Header relaxed<\/strong>I lower header names to lower case, remove superfluous spaces around colons, fold continued lines into a single line and reduce multiple spaces within header values to exactly one space. The order of the headers to be signed is retained according to the h= list, duplicates are taken into account in the order specified there.<\/li>\n  <li><strong>Header simple<\/strong>I leave each byte sequence exactly as sent. Every additional space, line folding or reformatting at intermediate stations breaks the check.<\/li>\n  <li><strong>Body relaxed<\/strong>I separate lines with CRLF, trim spaces at the end of the line, reduce several spaces between words to one and remove excess empty lines at the end of the body until at most one remains. A completely empty message is canonicalized as a single empty line.<\/li>\n  <li><strong>Body simple<\/strong>: I require an exact match of all lines including line endings. Even a converted line ending can cause the check to fail.<\/li>\n<\/ul>\n<p>These rules reflect typical transport changes: header folding, whitespace corrections, 7bit\/8bit conversions and different MTA implementations. By using relaxed, I shield cosmetic deviations without masking semantic manipulations.<\/p>\n\n<h2>Best practices: relaxed vs. simple<\/h2>\n\n<p>I almost always sign headers in a relaxed way, because small things like capitalization of header names or additional spaces make the <strong>Examination<\/strong> otherwise tilt unnecessarily. For the body, I also prefer relaxed, because normalized line breaks and trimmed spaces at the end of the line make for more <strong>Validity<\/strong> after transport adjustments. The combination c=relaxed\/relaxed delivers the most reliable results in heterogeneous infrastructures without weakening the cryptographic statement. I use Simple specifically in strictly controlled, internal environments in which I securely exclude format changes and the <strong>Path<\/strong>-stations. On the open Internet, simple brings unnecessary risks and frustrates responsible teams because valid messages fail. Anyone addressing inboxes from large providers will be much more relaxed with relaxed\/relaxed and save money. <strong>Support<\/strong>-time.<\/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\/05\/dkim_meeting_stabil4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Technical basis: DKIM signatures and keys<\/h2>\n\n<p>I work with a private key on the outgoing server and a public key as DNS TXT record under <strong>_domainkey<\/strong>, so that receiving systems can verify. The DNS record contains the version, key type and the Base64-encoded public <strong>key<\/strong>; the private key remains securely on the server. As soon as the recipient detects a DKIM signature, it queries the DNS record and checks whether the signature and domain match. This chain is only effective if I define the format, length and selector name correctly and the <strong>Filing<\/strong> of the private material. For the overall picture, please refer to the compact <a href=\"https:\/\/webhosting.de\/en\/spf-dkim-dmarc-bimi-explains-optimal-email-security-matrix\/\">Security matrix for e-mail<\/a>, which clearly organizes the roles of SPF, DKIM, DMARC and BIMI. The cryptographic statement of the <strong>Message<\/strong> traceable and permanently verifiable.<\/p>\n\n<h2>Header list, parameters and secure default settings<\/h2>\n\n<p>I control the stability of the signature not only via c=, but also via other DKIM parameters:<\/p>\n<ul>\n  <li><strong>h=<\/strong> lists the signed headers in the exact order in which they are used. I include stable fields such as From, To, Subject, Date, Message-ID and MIME-Version and dispense with volatile fields (e.g. Received, Return-Path, Authentication-Results, X-Header), which almost always vary en route.<\/li>\n  <li><strong>d=<\/strong> specifies the signing domain. For DMARC alignment, I select d= on the sender domain (or a suitable subdomain) so that recipients can clearly assign the identity.<\/li>\n  <li><strong>s=<\/strong> designates the selector. I use descriptive names with a date\/service reference (e.g. s=mail2026) to keep rotation and multi-client scenarios clear.<\/li>\n  <li><strong>t=<\/strong> contains a signature timestamp, <strong>x=<\/strong> optionally an expiration date. I set x= moderate so as not to unnecessarily overturn old, delayed mails.<\/li>\n  <li><strong>bh=<\/strong> is the hash of the canonicalized body and protects the integrity of the content. <strong>b=<\/strong> is the actual signature via selected headers and the body hash.<\/li>\n  <li><strong>l=<\/strong> I do not use body length tags because partial body signatures increase the risk of replay attacks. I prefer full body hashes for clear integrity.<\/li>\n  <li><strong>z=<\/strong> (copied headers) are generally omitted: hardly any added value, but potentially increased data protection and stability risks.<\/li>\n<\/ul>\n<p>I use RSA 2048 bit for the key strength. This is broadly compatible, performant and usually fits into DNS TXT records without provoking fragmentation. Longer keys can cause DNS and resolver problems; keys that are too short (1024) reduce security. I split the public key cleanly into 255-character strings, pay attention to correct quotation marks and avoid unintentional spaces.<\/p>\n\n<h2>Practical implementation on the mail server<\/h2>\n\n<p>I start with the key generation, define clear selector names and keep the <strong>Files<\/strong> are strictly separated on the server so that there is no mixing. I then publish the public key in the DNS, check the resolution and make sure that the semicolons, quotation marks and the length of the <strong>Records<\/strong>. In the server configuration, I define which domains are signed, which headers belong in the signature and which canonicalization I use, usually c=relaxed\/relaxed. I then send test mails to various mailboxes and analyze the header, body hash and the canonicalization used. <strong>Selector<\/strong>. During operation, I monitor delivery rates, feedback loops and DMARC reports and adjust the canonicalization or adapt the header list if there are any anomalies. In this way, I keep the technical basis clean and the <strong>Evaluation<\/strong> comprehensible.<\/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\/05\/mailsecurity-dkim-stability-2473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>MIME, character sets and transport conversions<\/h2>\n\n<p>I plan for MTAs and gateways to change content transfer encoding, character sets or line endings:<\/p>\n<ul>\n  <li><strong>Quoted-Printable vs. Base64<\/strong>Conversions between the two are common. Relaxed-Body-Canonicalization catches differences in whitespace and line endings, but semantic changes (e.g. repackaging MIME parts) break the signature.<\/li>\n  <li><strong>7bit\/8bit conversion<\/strong>Some systems convert 8bit to 7bit. Relaxed normalizes line endings, but if content is re-encoded or wrapped, only re-signing at the intermediate destination (e.g. for mailing lists) or ARC for the authenticity chain will help.<\/li>\n  <li><strong>Trailing Newlines<\/strong>I make sure that the body ends correctly with CRLF. Relaxed removes superfluous closing lines, simple does not - a common stumbling block.<\/li>\n  <li><strong>Empty bodies<\/strong>An empty body is defined in relaxed as a single empty line. I check this explicitly in tests to rule out edge cases.<\/li>\n<\/ul>\n<p>For HTML content, I monitor whether inliners, DLP scanners or link checkers change attributes or whitespace. If this is the case, I keep the number of signed, potentially affected headers small and insist on relaxed\/relaxed to cushion cosmetic interventions.<\/p>\n\n<h2>Avoid typical sources of error<\/h2>\n\n<p>I often see errors in the DNS record: inappropriate line breaks, missing semicolons or quotations prevent recipients from finding the public <strong>key<\/strong> load cleanly. Problems also arise due to a lack of synchronization during key changes if the DNS and server file are not in sync. <strong>run<\/strong>. Canonicalization that is too strict, such as simple\/simple, quickly fails with mailing lists, gateways or archiving and unnecessarily impairs deliverability. Signing too many, frequently changed headers is just as risky, because it can compromise the validity of the <strong>Signature<\/strong> vulnerable. I therefore use a balanced header list, focusing on From, To, Subject, Date and appropriate additions, and keep relaxed for headers and <strong>Body<\/strong> ready. This approach prevents chain reactions and saves time when troubleshooting.<\/p>\n\n<h2>Header and body canonicalization in comparison<\/h2>\n\n<p>In order to make decisions tangible, I summarize the effects of the modes in a compact table and add practical tips for <strong>Selection<\/strong>. The comparison helps you to find the right mode for your own <strong>Surroundings<\/strong> without creating blind spots.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspect<\/th>\n      <th>simple (Header\/Body)<\/th>\n      <th>relaxed (Header\/Body)<\/th>\n      <th>Practical note<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tolerance for spaces<\/td>\n      <td>Small, differences break down quickly<\/td>\n      <td>High, multiple spaces are standardized<\/td>\n      <td>For mixed routes <strong>relaxed<\/strong> prefer<\/td>\n    <\/tr>\n    <tr>\n      <td>Dealing with line breaks<\/td>\n      <td>Strict, format must fit exactly<\/td>\n      <td>Normalizes common variants<\/td>\n      <td>For gateways with reformatting <strong>relaxed<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Forwarding\/mailing lists<\/td>\n      <td>High risk of fractures<\/td>\n      <td>Significantly higher durability<\/td>\n      <td>Subject prefix and footers <strong>cushion<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Internal, controlled networks<\/td>\n      <td>Good choice for a homogeneous route<\/td>\n      <td>Also possible<\/td>\n      <td>Only use simple if all <strong>Stations<\/strong> are known<\/td>\n    <\/tr>\n    <tr>\n      <td>Recommended combination<\/td>\n      <td>c=simple\/simple rarely useful<\/td>\n      <td>c=relaxed\/relaxed for most cases<\/td>\n      <td>Header relaxed, Body <strong>relaxed<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>I always test changes with real target mailboxes, because synthetic checks do not check every mailbox. <strong>Route<\/strong> map. I also regularly check whether intermediate stations insert new headers or change the encoding and adjust the <strong>Configuration<\/strong> afterwards.<\/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\/05\/mailserver_sicherheit_2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring, DMARC and SPF in interaction<\/h2>\n\n<p>I evaluate DMARC reports to see how often DKIM or SPF takes effect at the receiver and correct the <strong>Settings<\/strong> as a result. SPF often fails with redirects because the redirecting server is not in the SPF record, which is why a reliable DKIM check is required. <strong>Sound<\/strong> is specified. I use a suitable DMARC policy to regulate how recipients deal with mails that do not pass SPF or DKIM. In doing so, I observe alignment rules so that the domain assignment between Header-From, DKIM-d and <strong>SPF<\/strong>-mailfrom fits together. For fine control, the <a href=\"https:\/\/webhosting.de\/en\/mailserver-spf-alignment-dmarc-policies-guide-security\/\">DMARC Policies Guide<\/a>, which outlines typical scenarios and side effects. The more consistently DKIM is carried through canonicalization, the more reliably it takes effect. <strong>DMARC<\/strong> in everyday life.<\/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\/05\/mailserver-sicherheit-4501.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ARC and mailing lists in the context of canonicalization<\/h2>\n\n<p>I take into account that mailing lists and forwarding services change content, which often invalidates the original DKIM signature. Two strategies help in everyday life:<\/p>\n<ul>\n  <li><strong>Re-signing<\/strong> by the list or the gateway: The intermediate station replaces the original signature with its own. This preserves integrity for the recipient, but DMARC alignment to the original sender is often lost.<\/li>\n  <li><strong>ARC (Authenticated Received Chain)<\/strong>ARC preserves the authentication results of the original delivery in a signed chain. This does not save a broken DKIM signature, but allows recipients to take the original authenticity into account.<\/li>\n<\/ul>\n<p>In practice, I keep canonicalization relaxed, reduce signed headers to robust fields and rely on ARC or re-signing for lists\/forwarders. In this way, I combine the consistency of the original signature with a traceable chain of authenticity along the route.<\/p>\n\n<h2>Multiple signatures, third-party providers and subdomains<\/h2>\n\n<p>I use several DKIM signatures for complex setups: for example, one signature from my main domain and another from a contracted shipping service provider. This gives me redundancy in case a signature becomes invalid due to format changes or re-signing. For DMARC alignment, I make sure that at least one signature matches the visible from domain (corresponding d= and subdomain policy if applicable). In client environments, I sign each sending identity with its own selector and key, keep keys and DNS records cleanly separated and clearly document responsibilities.<\/p>\n\n<h2>Troubleshooting: Header analysis and typical indicators<\/h2>\n\n<p>I take a structured approach to breakdowns:<\/p>\n<ul>\n  <li>I check <strong>Authentication results<\/strong>-Header at the receiver: Which method (DKIM\/SPF\/DMARC) passed, which failed, and which selector was used?<\/li>\n  <li>I compare <strong>bh=<\/strong> and <strong>b=<\/strong>If the body hash (bh=) does not match, I look for changes to line ends, spaces at the end of lines or inserted footer texts.<\/li>\n  <li>I check the <strong>h=<\/strong>-list: Has a header listed there been refolded, reordered or added to en route? Relaxed intercepts whitespace, but not semantic or sequence changes outside the defined rules.<\/li>\n  <li>I look at <strong>c=<\/strong>Is the test set to simple\/simple, although gateways are reformatting? Then I switch to relaxed\/relaxed and test again.<\/li>\n  <li>I check the <strong>DNS Key<\/strong>Can the TXT record be retrieved completely and correctly, are all segments correctly quoted and is the selector correct?<\/li>\n<\/ul>\n<p>By comparing emails to several large providers, I can identify patterns more quickly, as some MTA chains are \u201estricter\u201c than others. I incorporate my findings into canonicalization, header lists or process adjustments (e.g. smoothing whitespace before sending).<\/p>\n\n<h2>Key rotation and governance<\/h2>\n\n<p>I rotate DKIM keys systematically so that no outdated <strong>key<\/strong> is in the DNS for an unnecessarily long time and increases risks. Before each rotation, I check whether all services are using the new selector and have a transition phase ready in which both services can use the new selector. <strong>Selector<\/strong> are valid. After the switchover, I remove the old public key as soon as all outgoing systems are using the new configuration. I link this routine with calendar reminders, documented responsibilities and a test plan for <strong>Relapses<\/strong>. For the implementation I use the guide to <a href=\"https:\/\/webhosting.de\/en\/dkim-key-rotation-management-server-security-rotation-plan\/\">DKIM key rotation<\/a>, which describes clear steps and sensible intervals. This keeps the cryptographic chain clean, and the <strong>Administration<\/strong> remains clear.<\/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\/05\/dev_desk_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Briefly summarized<\/h2>\n\n<p>I rely on relaxed\/relaxed because it defuses small format changes and the <strong>Signature<\/strong> arrives validly at its destination more often. A clever selection of signed headers prevents manipulation without compromising the <strong>Consistency<\/strong> unnecessarily. Thorough tests with real mailboxes show where gateways change something and how I need to make adjustments. DMARC benefits significantly if DKIM remains reliably testable and SPF wobbles during forwarding, so I pay attention to clean <strong>Alignment<\/strong>. With organized processes for key rotation, clear documentation and monitoring, I keep operations safe and secure. <strong>maintainable<\/strong>. If you take these points to heart, you will reduce the risk of spam, protect your domain identity and noticeably increase your delivery rate.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how DKIM Canonicalization improves signature stability and why the focused keyword DKIM Canonicalization is crucial for secure mail servers.<\/p>","protected":false},"author":1,"featured_media":19554,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[708],"tags":[],"class_list":["post-19561","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-email"],"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":"87","_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":"DKIM Canonicalization","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":"19554","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19561","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=19561"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19561\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19554"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19561"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19561"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19561"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}